Re: Format strings are wrong
Ken Dickey <[email protected]> Thu, 4 Dec 2003 15:16:42 +0100
| Newsgroups | gmane.lisp.scheme.srfi.srfi-48 |
|---|---|
| Organization | BitWize Consulting |
| Message-ID | <[email protected]> |
> From: Charles Stewart <cas-+VuHOhYSxa2v/2WfcVMNQPhqMcnVdK/[email protected]> >... > 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