[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
exitlist in new-style DO
- To: ALAN at MIT-MC, Paul.Hilfinger at CMU-10A
- Subject: exitlist in new-style DO
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Mon, 23 Feb 81 06:02:00 GMT
- Cc: BUG-LISP at MIT-MC, Dave.Touretzky at CMU-10A
- Original-date: 23 February 1981 01:02-EST
Date: 21 February 1981 1540-EST
From: Paul.Hilfinger at CMU-10A
Is there some deep underlying reason why in the expression
(do ( ... ) (e1) ... )
MacLisp does not treat e1 as thelast element in the EXITLIST and returns
(instead) NIL? Grumble.
This change would affect tons of code and is not worth the effort. In fact,
I would argue that there is a 'deep philosophical reason' for having it return
nil... Reason? Well, you need a temporary variable in the underlying structure
otherwise. ie, the internal code for DO is conceptually:
... (IF (EVAL EXIT-TEST) (EXECUTE-IMPLICIT-PROGN EXIT-BODY) ... ) ...
and to get the effect you want, you have to do
... (LET ((TEST (EVAL EXIT-TEST)))
(IF (NOT EXIT-BODY)
or the equivalent. This is conceptually what COND does. In my book, it is
crock that COND does what it does when there are no expressions in the
consequent part of a succeeding clause because hair is required to make it
happen ... It is, however, a USEFUL crock, and one we have all grown used to.
It can at least be compiled well, and it's certainly not ambiguous...
So maybe that makes it less bad, maybe not. But the point is that I think
that DO should just stay as it is.
Date: 22 February 1981 19:28-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: exitlist in new-style DO
To: Dave.Touretzky at CMU-10A, Paul.Hilfinger at CMU-10A
cc: BUG-LISP at MIT-MC
... Of course you could write "(stop nil)" if that is what you really
wanted, right? If we are going to consider changing the behavior of
DO, perhaps we should consider removing this wierd case:
(do ( ... ) nil ... )
How many of you even know about the wierd thing that this is defined to
Yes, i did know what it did. It is kinda silly. It used to be useful before
LET was invented, actually, ... But there's no harm in leaving that in, really.
People should probably be encouraged not to use it, but there's not any point
in trying to break working code -- if there is any that uses the feature.