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 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