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