Subject: stream designator
From: Erik Naggum <>
Date: 1997/12/27
Newsgroups: comp.lang.lisp
Message-ID: <>

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.
    determines whether to return *STANDARD-INPUT* or *STANDARD-OUTPUT*."
       ((null stream-designator)
	(case direction
	  (:input   *standard-input*)
	  (:output  *standard-output*)
	  (t (error 'program-error
		    :format-control "~@<~S is not a valid stream direction~:@>"
		    :format-arguments (list direction)))))
       ((eq stream-designator t)
       ((streamp stream-designator)
       (t (error 'type-error
		 :format-control "~@<~S is not a valid stream designator~:@>"
		 :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.

The year "98" was new 1900 years ago.  |  Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"!  |