[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: floating point and other comments
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
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.