[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Inconsistency in various DOs
- To: MOON at MIT-MC
- Subject: Inconsistency in various DOs
- From: JONL at MIT-MC (Jon L White)
- Date: Sat ,12 Apr 80 19:19:00 EDT
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC
Date: 10 April 1980 05:17-EST
From: David A. Moon <MOON at MIT-MC>
Subject: Flushing old-style do
DO (old as well as new style) is very heavily used, and there is nothing
to be gained by flushing the old style other than an extremely minor
simplification of documentation.
Either you missed the first part of these communications, about syntax
of DO and DOTIMES, or you're simply confused. The "gain" for flushing
old-style DO is to free up the constraints on other DOers imposed
by the syntax which treats an atomic first "argument" as an abbreviated
variable specification, rather than a "name" for the DO. That is,
DOTIMES and other yet-to-be-invented DOers are constrained by popular
opinion to interpret an atomic first arg as a "name", rather than leaving
that for some other operation like DOTIMES-NAMED -- that was the only
practical point mentioned in all the mail to my inquiry about the syntax
(DOTIMES <symbol> ...).
As it happens, the LISPM blew it by not flushing old-style DO's
in the very beginning. Since all maclisp code had to be mildly "massaged"
to get it onto LISPM, there would have been no difficulty mechanically
rewriting the old DO into the new (actually, much maclisp code needed
a ***great*** deal more massaging than just a mechanical inspection);
at runtime, a "maclisp-support" flag would permit obslete constructs
to be used. As it also happens on LISPM, neither is there a DOTIMES-NAMED,
nor is the syntax (DOTIMES <symbol> ...) permissible for a named DOTIMES.
Of course, this inconsistency in the current situation is preferable
to the temporary perturbation that would result from trying to flush
old-style DOs, but it's a shame to perpetuate further inconsistencies
because of a failure to see the issues clearly.
Speaking of issues, how important a loss is it that there has to
be a DO-NAMED? How big a loss would it be to programmers if they
had to type PROG-NAMED rather than PROG? Admittedly these "named"
constructs are crucial to interpreters and compilers, but I'd be
curious hear what proportion of DO/PROG usages by J. Random Loser
actually use the "named" feature. If its extremely low (say, below 2%)
then it would seem counter-productive to constrain the future
language constructs just to save typeing a rare "-NAMED". The
Vision people, the Constraints guys, and the ACTOR builders might
be the logical ones to provide input here.