[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
- Subject: Re: *eof-value*
- From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
- Date: Wed, 29 Jul 87 09:39:29 EDT
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
>From: IN%"Steven Haflich <email@example.com>" 28-JUL-1987 01:59
>Although the proposed change is otherwise cogent, I
>would opt against it since the benefit is only minor convenience and
>not increased functionality.
But at no real cost, since the constant is going to exist anyway.
Perhaps I wasn't really clear. The important cost is that changing
the current default value of eof-value from NIL to anything else may
break existing code that depends on (READ stream NIL) returning NIL on
eof. Even though CL might be a better language if the spec were
changed in this regard, this rather minor improvement wouldn't justify
making an incompatible change, particularly since the desired
functionality can be achieved via (READ stream NIL *EOF-VALUE*).
By the way, exporting a new symbol such as *EOF-VALUE* from the LISP
package is an incompatible change, although often a more-easily
detectible one. The problem is that code written under the old spec
will suddenly find it's like-named internal symbol(s) "unified" with
the symbol in the LISP package. If it were really a CONSTANT (why?)
than presumably any user attempt to set or even DEFVAR it will signal
an error. But even innocently adding a new exported function name can
break code that happens to use that name either as a function or a
It will certainly happen that X3J13 will propose add new functions and
variables that must be exported from the LISP package. However, they
will weigh the cost of each such change and only make changes for
which there is a significant benefit that cannot otherwise easily be
obtained using the existing language definition.