[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
- To: cl-cleanup%sail.stanford.edu@multimax
- Subject: [Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Wed, 13 Apr 88 16:35:45 EDT
Jim asked me to forward this to the cleanup committee a while ago. I
think that it has some interesting ideas, but delves too much into
specifying implmentation for standards proposal.
------- Forwarded Message
Return-Path: @multimax.ARPA:edsel!jlm@labrea.Stanford.EDU
Received: from multimax.ARPA by mist.UUCP (3.2/4.7)
id AA23038; Wed, 2 Mar 88 10:00:47 EST
Received: by multimax.ARPA (5.51/25-eef)
id AA15330; Wed, 2 Mar 88 10:00:47 EST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:37:31 PST
Received: from bhopal.lucid.com by edsel id AA06372g; Tue, 1 Mar 88 11:47:41 PST
Received: by bhopal id AA05626g; Tue, 1 Mar 88 11:53:43 PST
Date: Tue, 1 Mar 88 11:53:43 PST
From: Jim McDonald <edsel!jlm@labrea.Stanford.EDU>
Message-Id: <8803011953.AA05626@bhopal.lucid.com>
To: pierson@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Mon, 29 Feb 88 18:55:14 EST <8802292355.AA19855@mist.UUCP>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Cc: edsel!eb@labrea.Stanford.EDU, edsel!jonl@labrea.Stanford.EDU,
edsel!lnz@labrea.Stanford.EDU, edsel!kdo@labrea.Stanford.EDU
Dan -- you might want to consider these comments I drafted a few weeks
ago. They're not quite in proposal format (the header is just for
your reference), but if you like the sense of this I can clean it up.
I think this is basically a generalization of your proposal (or at
least is more open-ended):
- -----
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by McDonald 3/01/88
Status: For Internal Discussion
A number of primitive streams are instantiated when lisp starts
(via the function primitive-streams), and the results of that
function are then used to build the higher level streams seen by
users.
- ------
primitive-streams &optional create-streams-p [function]
If create-streams-p is true, creates and opens primitive streams in
an implementation-dependant manner. Data associated with any
previously existing streams may be lost, and the effects of previous
calls to add-primitive-stream and delete-primitive-stream may be
lost. Normally, create-streams-p will be true for just a single
call made when lisp starts.
Always returns a list of triples of the form:
(<keyword> <input-stream or nil> <output-stream or nil>).
The following triples must be included in this list, but more are
allowed, and various of the stream objects may be eq:
((:terminal-input #<input-stream> nil)
(:terminal-output nil #<output-stream>)
(:standard-input #<input-stream> nil)
(:standard-output nil #<output-stream>)
(:error-output nil #<output-stream>)
(:query-input #<input-stream> nil)
(:query-output nil #<output-stream>))
It is an error to destructively modify this list or any of the
triples within it. Different calls to primitive-streams are free to
return eq lists or not, as convenient.
- ------
add-primitive-stream (keyword input-stream-or-nil output-stream-or-nil)
Causes a three element list of the arguments to be prepended to the
list of triples returned by subsequent calls to (primitive-streams).
Signals an error if the first argument is not a keyword, if the
second argument is not nil or an input-stream, or if the third
argument is not nil or an output-stream.
Returns NIL.
Note that this can be used to "shadow" :terminal-input, etc.
- ------
delete-primitive-stream (keyword)
The first triple starting with keyword which would otherwise have
been returned by (primitive-streams) will no longer appear in the
list of triples returned by (primitive-streams).
Signals an error if the argument is not a keyword.
Returns the triple which is deleted, or NIL if none existed, or
:ERROR if the triple selected may not be removed.
Note that this can be used to remove shadowing triples for
:terminal-input, e.g., but not all triples for it.
- ------
During lisp startup, two forms are executed:
(primitive-streams t)
(initialize-stream-variables)
Initialize-stream-variables is defined by default as follows, but
implementations and/or users, applications, etc., can redefine it or
simply reset or rebind the stream variables as they choose.
(defun initialize-stream-variables ()
(let ((primitive-streams (primitive-streams)))
(setq *terminal-io*
(make-two-way-stream
(second (assoc :terminal-input primitive-streams))
(third (assoc :terminal-output primitive-streams))))
(setq *standard-input*
(second (assoc :standard-input primitive-streams)))
(setq *standard-output*
(third (assoc :standard-output primitive-streams)))
(setq *error-output*
(third (assoc :error-output primitive-streams)))
(setq *query-io*
(make-two-way-stream
(second (assoc :query-input primitive-streams))
(third (assoc :query-output primitive-streams))))
))
- ------
Rather than mandating portability via some least common denominator,
this proposal makes stream initialization more of an open system, easy
to tailor to individual situations.
The rules are also intended to enable user code to be able to restore
*terminal-io*, *standard-input*, *standard-output*, *error-output*,
and *query-io* to reasonable values, even if all of them have been
set to NIL or other undesirable values.
The functional interface to the triples is designed to discourage
random tampering with sensitive data.
------- End of Forwarded Message