Re: floating point and other comments

[Alex Shinn <foof@xxxxxxxxxxxxx>]

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