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 implementation. Cheers, -KenD