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

Re: a preface

This page is part of the web mail archives of SRFI 54 from before July 7th, 2015. The new archives for SRFI 54 contain all messages, not just those from before July 7th, 2015.



 * From: David Van Horn <dvanhorn@xxxxxxxxxx>
 * Date: Wed, 24 Mar 2004 02:38:01 -0500
 * Subj: Re: a preface

   >> Title
   >> Formatting
 | Although succinct, this is completely nondescript, as is the identifier fmt.
   >> Abstract
   >> This SRFI introduces the FMT procedure that converts any object to a string.
   >> Unlike the procedure called FORMAT, this FMT procedure takes one object as the
   >> first argument and accepts several optional arguments.
 | This abstract doesn't outline the need for, and design of, the proposal as
 | required by the SRFI Process Document.
   >> Rationale
   >> The FMT procedure provides a handy optional and functional interface.
 | This rationale is less than detailed.

I don't think so.

   >> Specification
   >> 
   >> (FMT <number> [[<width>] [<depth>] [<char>] [<radix>] [<plus>] [<exactness>]
   >> [<space>] [<string>] ...])
   >> (FMT <others> [[<width>] [<count>] [<char>] [<show>] [<case>] [<space>]
   >> [<string>] ...]) 

 | The SRFI document must contain a detailed specification.  This should be
 | detailed enough that a conforming implementation could be completely created
 | from this description.  I don't think that is true of the current specification.

I have never seen any example of spec of this sort of parameters.
Let me know the way to describe this spec.

 
 | Regardless, allowing arbitrary order and arbitrary omission of arguments seems
 | an especially fragile way to specify a procedure.  This is why you have to
 | stipulate things like: "<depth> or <count> can be defined only after <width> is
 | defined."  If we add more parameters to fmt this problem will blow up, quick.

 | Why does fmt have two very distinct behaviors?  Why not have two distinct
 | procedures?

 | Why have a <show> parameter when you can just apply that function to fmt's
 | result?  And further, why are you allowed to pass in only display or write?

 | Why have <string> parameters when you have string-append?

I think they are FMT's forte.


Soo
-- 
INITERM