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

Re: Format strings are wrong



> From: Charles Stewart <cas@xxxxxxxxxxxxxxxxxxxxxxxxx>
 
>...
> Specific points and criticisms:
>  1. I think single letter escapes are fine: like mathematical
>  constants if you use or often read them, you'll remember them.
>  However, I would like it to be the case that you don't need to have
>  memorised the whole table to be able to tell consuming escapes from
>  non-consuming escapes (eg. upper case vs. lower case, alphnumeric vs.
>  other).
>
>  2. Is it good to have both ~? and ~K: why have backward compatibility
>  cruft in the first SRFI?  Explanation, please!

You probably need a better Lisp historian than I, but I believe most early 
Lisps (spelled LISPs then) inherited some form of FORMAT function from 
MACLISP [MIT/LCS/TT-295, The Revised Maclisp Manual, circa 1983 is the 
earliest reference I have].  I wrote a bunch of code in T and Scheme48 at 
various times and implemented a FORMAT function in 1988(?) which I ported to 
most Scheme's which did not have one.  SLIB picked up this version which was 
then generalized to the current CL "kitchen sink".

So one reason is that I am old and crufty enough to remember/use/rewrite a 
bunch of old code.

Another reason is to reserve "K" as a dispatch character to avoid breaking old 
code.  SLIB does this as well (but probably inherited from my code).

Personally, I don't use "~K", so am happy to drop it.  Note, however, that 
SLIB also allows "~K", so why not reserve it?

[As an exercise, you might take, e.g. Scheme48, search/grep for all uses of 
"format", and replace them with a new convention.  Get a concensus on the 
conventions, do the for all existing implementations which use some form of 
format currently and ...  Just kidding.  Pick a new name and make your 
proposal.  Blame MacLisp!  8^]


>  3. It seems to me the nicest functional formatter uses the standard
>  string concatenater together with quasiquotation.

As an implementor I don't think writing characters to a port should be held 
hostage to string concatenation.  You are welcome to supply your own 
implementation.

Cheers,
-KenD