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

Cheers,
-KenD