floating point and other comments
Alex Shinn
(18 Dec 2003 02:58 UTC)
|
Re: floating point and other comments
Ken Dickey
(18 Dec 2003 16:17 UTC)
|
Re: floating point and other comments
Alex Shinn
(19 Dec 2003 01:55 UTC)
|
Re: floating point and other comments
Ken Dickey
(20 Dec 2003 02:34 UTC)
|
Re: floating point and other comments
Alex Shinn
(20 Dec 2003 08:56 UTC)
|
Re: floating point and other comments
bear
(20 Dec 2003 19:00 UTC)
|
Re: floating point and other comments
Alex Shinn
(22 Dec 2003 02:16 UTC)
|
Re: floating point and other comments
bear
(23 Dec 2003 02:01 UTC)
|
Re: floating point and other comments
Alex Shinn
(23 Dec 2003 04:38 UTC)
|
Re: floating point and other comments Ken Dickey (22 Dec 2003 02:56 UTC)
|
Re: floating point and other comments
Per Bothner
(20 Dec 2003 18:05 UTC)
|
Re: floating point and other comments
Ken Dickey
(22 Dec 2003 00:41 UTC)
|
Re: floating point and other comments
Alex Shinn
(22 Dec 2003 03:50 UTC)
|
Re: floating point and other comments
Ken Dickey
(22 Dec 2003 17:05 UTC)
|
Re: floating point and other comments
Alex Shinn
(23 Dec 2003 05:23 UTC)
|
Re: floating point and other comments
Alex Shinn
(23 Dec 2003 05:26 UTC)
|
On Saturday 20 December 2003 09:56 am, Alex Shinn wrote: > One minor question, what case does ~x use for hexstrings? R5RS > doesn't specify this for number->string. An interesting extension > some schemes use is to use the case of the x (i.e. distinguish between > ~x and ~X). I would prefer that the case of ~X matches the case of the hex characters, but can't specify more than R5RS here. Note that the reference implementation maes use of NUMBER->STRING. > Also, the spec says it is an error to pass fewer arguments than > needed, but is it ok to pass more arguments? I consider it useful to detect this as an error, but there are other sensible ideas. E.g. one possible return value for FORMAT is the list of unused arguments. I prefer that FORMAT invoke ERROR rather than failing and returning #F, as SLIB specifies. However, I prefer to leave FORMAT's return value unspecified in srfi-48 and come to concensus on an advanced format srfi. Cheers, -KenD