[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

Wednesday  June 14,1978   FQ+1D.8H.19M.18S.   LISP 1633  -HIC-

Changes that affect ITS NEWIO:
[1] PUSH, POP, and DISPLACE FEXPR's in interpreter
This was what was announced in Lisp news a month afterward. I think it's
fine if it was originally intended for use with MACRO's but it was given
a very precise definition if you ask me ... The fact that it was later
extended to handle DISPLACE'ing atoms into itself was not unreasonable
as it provided an upward compatible extension. The proposed change that you
are asking for is not upward compatible. It says that if it fails to 
accomplish what it has been documented to do, it may not err out and I
may just find out later at random ... I have used DISPLACE all over in my
code because it was defined in a general fashion. I like the definition as
is and find it immensely useful.

Take an example of SUBST -- its stated purpose is to do substitution -- it
was only an accident that it does copying. Would you say then that it is
reasonable to change how it operates -- perhaps making it more conservative
about copying, like SUBLIS is? I should hope not.

I think a 2-year-old description of the functionality of something should
stand. HIC chose to document its function, for good or bad, in Lisp. If
the function has any contract, that is surely it.

I see a very bad thing happening to MacLISP in recent days. It is being
treated more and more like a set of midas macros for booting up a better
lisp. While I think it is good to see the new semantics brought about,
I do not agree that the way to do it is to introduce funny little variables
here and special case crocks there that only serve to support the 
implementors of the up-and-coming world and generally make the language
harder and harder to explain, less and less elegant ... Maybe the thing
to do is freeze MacLISP and then we wouldn't have to worry. Existing
code could continue to run -- new code could be developed for NIL and