designators is a constant source of mixed feelings for me. on the one
hand, they're very convenient, but on the other, they're a pain in the
butt. a function that takes an input stream designator (like `read' does),
for instance, needs to compute the denoted stream if it wishes to produce
proper condition objects. in the general case this turns into something
like this:
(defun stream (stream-designator &key (direction :input))
"Return the stream object denoted by STREAM-DESIGNATOR.
If STREAM-DESIGNATOR is NIL, DIRECTION (which must be :INPUT or :OUTPUT)
determines whether to return *STANDARD-INPUT* or *STANDARD-OUTPUT*."
(cond
((null stream-designator)
(case direction
(:input *standard-input*)
(:output *standard-output*)
(t (error 'program-error
:format-control ··@<~S is not a valid stream ···········@>"
:format-arguments (list direction)))))
((eq stream-designator t)
*terminal-io*)
((streamp stream-designator)
stream-designator)
(t (error 'type-error
:format-control ··@<~S is not a valid stream ············@>"
:format-arguments (list stream-designator)
:datum stream-designator
:expected-type '(or (eql t) (eql nil) stream)))))
... except, of course, that using the intuitive name `stream' for this
(global) function is a violation of the language specification. *sigh*
for a number of other designators, there are "resolvers" available in the
language specification, like `character' or `string', but not for `stream',
which needs it more than most of the others, in my view, since it is much
harder to get right, and since it would be so much nicer to write functions
that behaved like the builtins, especially if they only were slightly more
complex or differed slightly from the builtins.
#\Erik
--
The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/
Erik Naggum <······@naggum.no> writes:
> (defun stream (stream-designator &key (direction :input)) ...)
> ... except, of course, that using the intuitive name `stream' for this
> (global) function is a violation of the language specification. *sigh*
I usually make it a macro called ASSURE-STREAM so that it can SETQ the
stream designator variable back. ;-)
> for a number of other designators, there are "resolvers" available in the
> language specification, like `character' or `string', but not for `stream',
> which needs it more than most of the others, in my view, since it is much
> harder to get right, and since it would be so much nicer to write functions
> that behaved like the builtins, especially if they only were slightly more
> complex or differed slightly from the builtins.
I'd have no opposition to making a proposal to add a function (similar to
PATHNAME) which parsed a stream. One pitfall you didn't mention that I see
most programmers just plain get wrong in code is that FORMAT has its own
incompatible convention. Hence, people often incorrectly assume that T means
*standard-output* for print or that T means *terminal-io* for format. Sigh.
I wish FORMAT NIL had never been invented.
--Kent (on vacation, but sick and bored, so taking some refuge in newsgroups
between naps)
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Erik Naggum <······@naggum.no> writes:
>
>> (defun stream (stream-designator &key (direction :input)) ...)
>> ... except, of course, that using the intuitive name `stream' for this
>> (global) function is a violation of the language specification. *sigh*
>
>I usually make it a macro called ASSURE-STREAM so that it can SETQ the
>stream designator variable back. ;-)
My thought was to give it an accessor-like name like
STREAM-DESIGNATOR-STREAM.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.