[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.

> > On Thursday 18 December 2003 03:55 am, Alex Shinn wrote:
> > > ... I think that an intermediate format should at least ... include
> > > support for floating point formatting with ~F (I think ~E and ~G would
> > > be advanced).

I agree with your motives, but as a scheme implementation is not required to 
support floating point, I can't see adding such support here.

I will be happy to work with you on an "advanced format" spec which includes 
this if you would like.

On Friday 19 December 2003 02:52 am, Alex Shinn wrote:
> 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.

I agree.  Rather than hashing out something here, I have removed ~p from the 
list of options.

> 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 am attempting to do _zero_ design in srfi-48.

> 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.

There was a Scheme Workshop held on 2003/11/07 which I believe is kicking off 
a new language standard working group.  According to the Scheme weekly news 
report, this aspect of records was on the list of things to address.  [Sorry, 
I don't have the URL handy].

> 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.

Again, I would be happy to support you in making such a proposal.