[bug#67842] [PATCH 4/4] services: mympd: Refactor serialization process.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Samstag, dem 16.12.2023 um 19:36 +0000 schrieb Bruno Victal:
> Hi Liliana,
> 
> On 2023-12-16 01:44, Liliana Marie Prikler wrote:
> > Am Freitag, dem 15.12.2023 um 21:02 +0000 schrieb Bruno Victal:
> > > -(define-maybe/no-serialization integer)
> > > +(define-maybe/no-serialization exact-integer)
> > At the risk of asking a silly question, what's the difference
> > between an integer and an exact integer?
> 
> IIUC it has to do with whether a decimal point is present or not,
> which influences the serialization process. (e.g. having port set
> to 8080.0 doesn't make much sense even though it is an integer)
I don't think we have to make this distinction that often, though; and
if we do, there are more fitting descriptions like signed-integer and
unsigned-integer.  Even if it's to guard against silly inputs, most
folks wouldn't write 8080.0 there.

> --8<---------------cut here---------------start------------->8---
> $ cat integer-dem.scm
> #!/usr/bin/env -S guile --no-auto-compile
> !#
> 
> (for-each
>  (lambda (s)
>    (format #t "Formatted output: ~a~%" s)
>    (format #t "number->string: ~a~%" (number->string s))
>    (format #t "Integer? ~a~%" (integer? s))
>    (format #t "Exact-integer? ~a~%" (exact-integer? s))
>    (newline))
>  (list 64 128.0))
> 
> $ ./integer-dem.scm
> Formatted output: 64
> number->string: 64
> Integer? #t
> Exact-integer? #t
> 
> Formatted output: 128.0
> number->string: 128.0
> Integer? #t
> Exact-integer? #f
> --8<---------------cut here---------------end--------------->8---
> 
> > >    (port
> > > -   (maybe-port 80)
> > > -   "HTTP port to listen on.")
> > > +   (maybe-exact-integer 80)
> > Losing the information that this is a port (i.e. only integers that
> > fit
> > into a uint16 are valid) is imho not great.
> 
> I'm not too happy with this either, though in hindsight I think
> redefining 'port?' (from Guile Ports) was a bad idea. At the moment
> the (re)defined port? predicate only checks whether the value is an
> integer, so switching it to exact-integer doesn't seem to change
> things much. (other than being stricter in criteria)
Maybe port-number? is clearer?

> Alternatively we could have a proper predicate, perhaps named ip-
> port? that would not only perform the exact-integer? check, but also
> test whether it fits within a uint16. I'm more inclined to introduce
> this kind of change in a separate series that would define it in a
> reusable manner and perform a cleanup run across the existing
> services though.
From my point of view you are already introducing "this kind of change"
as not a separate series :)

Cheers