This page is part of the web mail archives of SRFI 48 from before July 7th, 2015. The new archives for SRFI 48 contain all messages, not just those from before July 7th, 2015.
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