[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: floating point and other comments
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
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.