Email list hosting service & mailing list manager

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)

Re: floating point and other comments Ken Dickey 21 Dec 2003 16:59 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