[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FORMAT
- To: Scott Turner <srt@UCLA-CS.ARPA>
- Subject: Re: FORMAT
- From: rees@DECWRL.ARPA
- Date: Mon ,28 May 84 13:27:00 EDT
- Cc: t-discussion@yale
- In-reply-to: Your message of Sat, 26 May 84 11:18:54 PDT. <8405261839.AA00453@decwrl.ARPA>
From: Scott Turner <srt@UCLA-CS>
Date: Sat, 26 May 84 11:18:54 PDT
How about extending FORMAT so that users may define their own formatting
codes (~P to call the pretty-printer, for instance)? It seems like this
would be easy to do, and very useful (although abusable).
To rephrase Kent Pitman on this issue: the problem here is scope. User
A and user B could easily have conflicting notions over what ~Z ought
to mean, and so their programs wouldn't work together. (This is a real
problem on the Lisp Machine, for example, which has a single global
namespace of FORMAT codes.) One would need to have FORMAT code tables
(like read tables or syntax tables) to be passed in as arguments to
FORMAT. The obvious implementation of this would be clumsy but one
could do something like
(define format (make-formatter))
Anyhow, this seems like just one more piece of randomness to add to T,
which already has enough lard. And FORMAT is already a mess; before
extending it, it would be good to look for a better way to do formatted
ouput in general. On the other hand, it's easy enough to do; we'll
consider it.