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

This completely cretinous argument about GET and hunks



To JONL and KMP, and whoever else cares:

   While I realize that in the area of law, the law of the land is the
legislation that was passed and not what the legislators intended to
pass, I think that in this situation the "reasonable man" and
"reasonable intent" principles apply.  I observe that nearly all of the
quoted "documentation" (and I use horror quotes, for LISP RECENT is
certainly a horrible excuse for documentation) came from my hand.  You
may well question whether I can be considered "reasonable" after
implementing hunks.  Nevertheless, if anyone had thought to ask me
earlier, I would have been happy to clarify the original intent and
design philosophy behind hunks.  (This is not to say that the future of
MacLISP must needs be confined by previous poor decisions.  On the other
hand, the past may be the best source of light for the future.)

   Hunks were originally invented to satisfy *two* applications:
(1) to provide record structures more memory-efficient than lists;
(2) to provide for list cells that could have properties attached.
I thought at the time that LISP RECENT made this fairly clear,
if not explicitly, then by example.

   The functions which were explicitly enumerated were not meant to be
the only functions which could treat hunks as lists.  It would have been
infeasible to list all such functions.  The fact that CAR and CDR were
listed as treating hunks as list cells, and the fact that ATOM of a
hunk produced NIL, together were considered sufficient informal notice
that all functions (such as GET and ASSQ) which are conceptually not
primitive, but use CAR, CDR, and ATOM, would also treat hunks as list
cells.

   Indeed, the intention was that hunks should always be treated *by
default* as list cells, *unless otherwise specified*.  This was the
reason for the HUNKP switch, and for the explicit mention of functions
such as PRINT and EQUAL:  the HUNKP switch conceptually does *not*
explicitly cause EQUAL and PRINT to treat hunks as list cells; instead,
permits the altering of that *default* behavior to make these
explicitly mentioned functions consider all components of a hunk
instead of just the car and cdr.

   Conclude from these remarks what you will.  Let me chastise both of
you, however, for your increasingly rude behavior in this interchange
and in previous messages to BUG-LISP and LISP-FORUM.  I am quite weary
of examining my mail every day or two only to find that much of it
contains snide remarks and allusions to someone's purported ignorance
or pigheadedness.  Such remarks are unnecessary to the transaction of
business in this public forum, and serve only to ruffle feelings and
impede progress.  (I have similar complaints about unnecessary and
uncalled-for use of profanity by yet other parties.)

--Guy