[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: floating point and other comments

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.