[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: GLS at MIT-MC, JONL at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC
- Subject: PROG-LET
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Thu, 10 May 79 22:32:00 GMT
- Original-date: 10 May 1979 18:32-EDT
I don't think that PROG is particularly pretty anyway and
for this reason am not really in favor of the idea of hairing
it up like LET to make it more 'fashionable'.
I also disagree with the idea of extending each of these things
one at a time. If you are going to extend PROG, it would make sense
to extend PROGV (did it make its way into NIL?) and any other operators
that do this sort of binding, perhaps adopting some regular naming
system so that there wouldn't be a lot of hard names to remember.
Otherwise, I fear a lot more hair will be called for in manuals. ie,
(LAMBDA <type-A-bvl> <body>) ; Atom or list of atoms
(PROG <type-B-bvl> <body>) ; list of atoms
(PROGV <type-C-bvl> <vals> <body>) ; evaluates to list of atoms
(LET <type-D-bvl> <body>) ; atoms, structures, you name it...
(DEFUN <name-specs> <type-E-bvl> <body>) ; all that and more (&AUX,...)
(DO <type-F-bvl> <exit-stuff> <bvl>) ; extended subset of LET syntax
I think it would be nice to move toward regularizing at least some
of these that are similar, so that the language does not develop infinitely
many special cases. (eg, in (shudder) Fortran, one of the common gripes is
having to remember that this form takes arbitrary expressions, this one only
takes integers, this one any integer or variable that is positive, ...)
One point in favor of the making PROG itself extended... the form
(PROG (BASE IBASE FOO BAR)
(SETQ BASE 10. IBASE 10.)
has within it a timing screw that forces one to do
(LET ((BASE 10.) (IBASE 10.) (FOO) (BAR))
or the even worse
(DO ((BASE 10.) (IBASE 10.) (FOO) (BAR)) () ...).
Why? If ^B is typed (or some error (eg an interrupt loses)) and
a breakpoint results, you get a bad value for IBASE error. Forcing
the programmer to give up PROG for a non-looping DO or nested LET/PROG
seems even more ugly than the original idea of just using a PROG...
Btw, to whoever suggested having LET destructure into PROG (if PROG
had this feature installed), - that would leave no guard against
having GO's and RETURN's in the LET. People with programs like:
... (LET (...) ... ( ... (RETURN T) ...) ...) ...)
would find themselves (provided they got past the dot context errors)
with a program that didn't run the way they meant it to any more...
So let's not even consider that idea.
ps Isn't one of these addressee's redundant? (BUG-LISP or NIL)
- I forget which one