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 18 Dec 2003 07:19 UTC

On Thursday 18 December 2003 03:55 am, Alex Shinn wrote:
> ... I think that an intermediate format should at least be a
> superset of C's printf functionality; specifically it should include
> support for floating point formatting with ~F (I think ~E and ~G would
> be advanced).

Unless more complex parameters (and a more complex implementation) are
required, I don't see the use of ~F.

SRFI-28 already outputs all supported numeric types:

(format "~a ~a ~a ~a~%" 32 1/2 0.03 (sqrt -4))
;;-> 32 1/2 0.03 0.0+2.0i

and SRFI-48 adds radix:

 (format #t "#d~d #x~x #o~o #b~b~%" 32 32 32 32)
;;-> #d32 #x20 #o40 #b100000

At last glance ANSI C had no support for binary output of numbers, so I don't
think we are subsetting printf.

Note that there is no attempt in SRFI-48 to "compete" with C.

> I don't think ~P belongs in the intermediate version, but would
> recommend reserving that character for the advanced version for
> backwards compatibility.  With one-letter names, some of them are going
> to be poor mnemonics no matter what so you might as well be consistent
> with CL.

The attempt is to agree on common usage across Scheme implementations, many
(most?) of which already supply a format function for some years/decades now.

> Shouldn't we have a pretty-printing SRFI before using it in our format?

The reference implementation already specifies the low bar here.  8^(

There are a number of pretty-print implementations available with various
interfaces.  Pretty-print is just too useful for human readers large lists.
I would not like to hold format hostage to agreement on a pretty-print
interface.

It is up to the implementation to deal with the implementation details of ~Y.
You might consider this a "stealth" SRFI for pretty-print.  ;^)

> I agree with the arguments for a more functional style, but think this
> should be implemented by breaking the format specs into separate public
> procedures and having the format procedure dispatch to them.

All good ideas, but specification of implementation details is beyond the
scope of the SRFI's.

Cheers,
-KenD