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.
At Thu, 18 Dec 2003 08:19:32 +0100, Ken Dickey wrote: > > 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. Sorry, I should have made it more clear that I intended ~F to support at least the first two comma parameters. Implementation of parameter parsing is trivial and handled in the link I gave (along with everything but the "programmatic" aspects of CL format). > At last glance ANSI C had no support for binary output of numbers, so I don't > think we are subsetting printf. But not supersetting it either. Scheme is the only language I know without any way to specify the decimal precision when displaying a floating point number. It's a fundamental operation, a solved problem, implemented in various inconsistent ways in most Schemes, and a huge pain in those few Schemes who don't support it, so it seems to me like a very good candidate for SRFI specification. However, it may be better to write an "Extended string->number" SRFI first that takes the decimal precision after the radix, or maybe use a separate procedure altogether. > > 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. Yes, that's what I said :) I just think ~P is a broken concept and would like to see some discussion about either dropping it or making it more i18n friendly. We can discuss that for SRFI-48, or put it on the back-burner for now but reserve ~P. > 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. OK, but I'd still like to see a pretty-print SRFI. Anyone? :) > > 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. As I understood from one of your earlier messages, by not specifying many of the common format features in this SRFI you were taking a "modest, sure to be approved" approach, with the possibility of future "advanced" format SRFI's. If you were to include the hierarchical design into this SRFI, then future additions are simply a matter of adding new specs and implementations can choose as to how far in the hierarchy they want to support. I'm also concerned about poor factoring in existing SRFI's. SRFI-35 has built into it essentially an inherited record type. This is a very useful feature by itself, and had already been proposed on the rrns-authors list. Not having this as an extension to SRFI-9 prevents code reuse. This would also be needed if you wanted to take a "baby-steps to OO system" approach: first make records inheritable, then you can have a separate SRFI specifying dispatch on record type. SRFI-44 effectively requires such simple dispatch but doesn't specify it and the reference therefore depends on Tiny-CLOS, which became a matter of huge debate. Likewise, SRFI-48 and SRFI-19 both specify format-like operations, and I frequently define custom format procedures for things like web-server log formatting and Emacs modeline formatting, etc. A meta-format SRFI would make it easier to specify these custom formats in a consistent and portable way. In retrospect though, SRFI-19 is somewhat different in that it doesn't consume the arguments. This could be solved by specifying in addition to the dispatch procedure a numeric value for number of arguments consumed. -- Alex