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

Re: Format strings are wrong

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.

> 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