On Tue, Sep 03, 2002 at 12:35:50AM +0200, Antonio Martínez wrote:
> A negligible patch for %inspect which fixes end of file bug (*), is a
> step towards flushing named-let :), control structure seems
> (subjectively) clearer.
> I left the EOF handling alone. (Like the toplevel, but unlike the
> debugger, EOF is handled in a Unix-consistent manner.)
Yes, it is unlike the debugger.:-(
These days I'm inclined to believe that the way the debugger does it
is better, but I think an earlier revision of myself disagreed.
> Apologies if the diff isn't good quality, I couldn't connect to sf
> tonight for some reason.
It is easier to understand diffs when they only show the changed
parts. Things like
> - (multiple-value-bind (description named-p elements)
> - (inspected-parts *inspected*)
> + (multiple-value-bind (description named-p elements)
> + (inspected-parts *inspected*)
are kind of a pain.
> (*) The "KMP idiom" is for unreadable streams, I think. Entering
> #.*standard-input* in the inspector exits the inspector loop, which
> I'm guessing is a bug, but I dare say this assumption will turn out to
> be one more dust-famished newbie expectation.
Yes, using that end-of-file test idiom here does seem to be a bug,
since it gives a surprising result for #.*STANDARD-INPUT*, which is
legal input. (rather devious legal input, but still...)
As to NAMED-LET, I came to Common Lisp from Scheme, so to me named LET
doesn't seem particularly strange. While TAGBODY is more standard
Common Lisp, I'm not convinced it's clearer. When I see a long TAGBODY
I start to wonder how many tags might be scattered around in it, and
whether there might be GOs forward as well as back. A named LET only
has one tag, and it always branches backwards. To me it seems sort of
like the difference between writing nonstandard
(dovector (i v)
(dotimes (ii (length v))
(let ((i (aref v ii)))
Because of the greater generality of the standard constructs compared
to the nonstandard specialized DOVECTOR, I find I need to read a
little more carefully to make sure I understand what's going on.
(I wouldn't recommend named LET in most Common Lisp application code,
since you can't in general rely on a Common Lisp compiler optimizing
away tail recursion. But for use inside SBCL itself, where there's no
need for portability so we can safely rely on understanding tail
recursion issues, it seems OK.)
So my initial reaction is that I'd be likely to merge your
HANDLER-CASE code to deal with end of file (since a surprising
response to #.*STANDARD-INPUT* seems more wrong than a surprising
response to even-more-devious #. constructs) but that I might leave
the NAMED-LETs alone.
(sorry I always end up arguing about aesthetics on your patches...)
William Harold Newman <william.newman@...>
#.(ERROR 'END-OF-FILE :STREAM *STANDARD-INPUT*) :-)
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C