[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
- To: masinter.pa%Xerox.COM@multimax
- Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Thu, 26 May 88 11:40:03 EDT
- Cc: cl-cleanup%sail.stanford.edu@multimax
- In-reply-to: Your message of 23 May 88 17:21:00 -0700.
Wow. I was about to button "Deliver" on a message poking you on this one...
Yes, well, there seem to be a lot of holes around nowdays...
I must admit that I didn't read earlier versions with much attention.
I am uncomfortable with the imperative style of this proposal (and of
CLtL). I can easily imagine implimentations conforming to the spirit
but not conforming to the letter of this proposal. Suppose, for
example, I have a program that records user input and is able to
duplicate it later. The second time I run it, it isn't an
"interactive" input stream, but does this mean I can't legally attach
it to *QUERY-INPUT* because reading from *QUERY-INPUT* must result in
This seems to be what Moon wanted at the March meeting. I sort of
doubt that it will meet universal acceptance, but promised to move
back in this direction for the third draft.
In many multi-processing multi-window environments, the "initial
binding" for *STANDARD-INPUT*, *QUERY-INPUT* differs for each
This is not specifically addressed, though you could stretch a point and
claim that all of the window loopholes cover it. I'll think about
adding something, but probably not to today's draft. The problem is
that the original goal of supporting the "standard streams" of the
underlying environment breaks down completely in a multi-window,
multi-process Lisp, if only because you don't bring up all that hair
just to run a shell-level batch job.
Your latest VERSION makes reference to *INITIAL-INPUT* and *INITIAL-OUTPUT*
still, even though you removed those items from the definition.
Sorry about all that, it'll teach me to re-edit a proposal quickly. A
new version will be going out today with all of that garbage fixed up.
I don't know how to say it more kindly, but I think this is a step
backward from version 2.
The cleanliness of the proposal certainly was a step backward, sorry.
The content is harder. I've never expected this version to be
accepted unchanged, so I've saved a copy of version 2. Should I put
out a new draft with both versions as alternate proposals? I'm really
reluctant to cop out that way without a very good reason.
It sounds to me like you would be happier with the original "specify
as little as possible" approach which was rejected in the first