[Scheme-reports] Three really picky points Vincent Manis (11 Jan 2012 03:29 UTC)
Re: [Scheme-reports] Three really picky points Alex Shinn (11 Jan 2012 03:41 UTC)
Re: [Scheme-reports] Three really picky points Vincent Manis (11 Jan 2012 06:33 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (11 Jan 2012 07:10 UTC)
Re: [Scheme-reports] Three really picky points Alex Shinn (11 Jan 2012 13:43 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (11 Jan 2012 17:32 UTC)
Re: [Scheme-reports] Three really picky points Alex Shinn (12 Jan 2012 12:48 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (11 Jan 2012 18:21 UTC)
Re: [Scheme-reports] Three really picky points Vincent Manis (12 Jan 2012 00:57 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (13 Jan 2012 01:28 UTC)
Re: [Scheme-reports] Three really picky points Vincent Manis (13 Jan 2012 02:02 UTC)
Re: [Scheme-reports] Three really picky points Vincent Manis (14 Jan 2012 18:35 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (15 Jan 2012 10:05 UTC)
Re: [Scheme-reports] Three really picky points Alex Shinn (15 Jan 2012 11:23 UTC)
Re: [Scheme-reports] Three really picky points John Cowan (15 Jan 2012 20:42 UTC)

Re: [Scheme-reports] Three really picky points John Cowan 15 Jan 2012 10:04 UTC

Vincent Manis scripsit:

> I couldn't find anywhere in the Draft that described the
> relation between numeric conversion in string->number, read, and in
> source programs, and was hoping for some kind of clarification (or a
> pointer to where I missed the clarification).

I did file a ticket for the WG to clarify this.

> The syntactic issues relate to such things as whether S, F, D, and L
> are valid (`the implementation *may* accept...', p. 32). Pragmatic
> issues include whether integer or other literals might overflow
> (on a bignumless implementation), whether or not the implementation
> applies the same restrictions, described at the bottom of p. 37) to
> string->number, read, and literals in source programs; the default
> precision if the E exponent marker is used; and numerical roundoff
> on input conversion (whether, e.g., (= (string->number? 0.1) 0.1)
> is defined to be true).

Added to the ticket at http://trac.sacrideo.us/wg/ticket/327 .

> It's obvious that string->number and read should use the same
> conversion routine;

That's what I thought too.  But Chibi uses two different routines, because
`read` terminates on the first delimiter, whereas string->number returns
#f if not all of the string is a number.  Still, that doesn't mean they
should not be consistent.

> So I think I'd prefer a statement that says that the relationship
> between literals in source programs on the one hand and string->number
> and read on the other is unspecified, but that the latter two use the
> same conversion rules.

Also added to the ticket.

--
John Cowan              cowan@ccil.org          http://www.ccil.org/~cowan
Historians aren't constantly confronted with people who carry on
self-confidently about the rule against adultery in the sixth amendment to
the Declamation of Independence, as written by Benjamin Hamilton. Computer
scientists aren't always having to correct people who make bold assertions
about the value of Objectivist Programming, as examplified in the HCNL
entities stored in Relaxational Databases.  --Mark Liberman

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports