GNU bug report logs -
#67842
[PATCH 0/4] Refactor mympd service.
Previous Next
Full log
Message #26 received at 67842 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 1 year and 186 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.