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


  Again let's put this into perspective.  Franz has implemented c{a,r}+r
closure for many years and I have never heard a complaint or even a comment
about it from anyone until gjc just mentioned it.  Aparently no one here
thinks that it is unusual to define all c*r, they are lisp programmers
not implementors and all they want it is a uniform language.  If they then
moved their code to one of the lisps which only partially implement c*r,
they would undoubtably call it a 'hacky' system.  Thus when you refer
to the c{a,d}r HACK, it is not clear whether you are refering to systems
which close over car and cdr or those that do not.
  As for the implementation, no one here has ever questioned that and I
am not even going to say how it is done, since that doesn't have any 
bearing on this discussion.  To the typical lisp programmer, it looks like
all c*r functions are defined in the initial lisp.  [The clever programmer
could watch the storage use counts and figure what functions were manufactured
on the fly].  In response to ACW, we don't view the manufacture of the
c*r functions as a 'feature' of the system which then the user should
have control of.  It is simply a action we must take to provide a uniform
language.  If we could obtain infinite time and space we would define all
c*r functons in the initial lisp and throw out the manufacturing.
As for the multiple oblist questions, franz only has one oblist, but if
it were possible to make new ones then whether they had c*r defined would
depend on whether the user asked for a copy of an oblist with c*r defined
or whether he asked for an empty oblist.  In the former case c*r would
be defined, in the later case it would not.

Now that we have this defined, why should we as lisp implementors remove it?
ALAN, you removed it from the lisp machine.  Was it because:
1) users came to you saying "Please, please remove us from the temptation of
   cdddddr and deliver us unto the the path of data abstraction".
2) it was a poor implementation to begin with and/or it conflicted with
   a later hack you wanted to make.
3) you felt that people who wrote cdddddr should be punished and lacking
   50Kv seats, you figured that a few 'undefined function' error messages
   should teach them a thing or two.
What if you decide tomorrow that 'plus' should have no more than 4 arguments
to prevent confusion?  Or that the evil 'go' statement will not longer exist.
My point is that the implementor should not inflict his prejudices on 
his community.  

  Regarding what is clear and what is not.  It is true that 'caddadr' is
pretty confusing but not because of its size, for example 'cadddar' accesses
the fourth element of the first part of a list.  Thus it is the form of
the c*r not the size which makes it understandable or not.

 My pet peeve are programs which have the capability to do something useful
for the user but fail to.  If I was sitting a lisp machine with a hairy
list structure in front of me and I wanted to see the fourth element
of the first subpart of a list, and I typed '(cadddar x)' and it said
that cadddar was an undefined function, I would be pretty disgusted.
I think that what I wanted to do is clear to everyone who has ever heard of
the language lisp, but to have the machine fail to do what it should just
because it is distasteful to the implementors is pretty sad and I would
probably boot the machine down the stairs.