ANSI spec for GETF
Jeff Barnett
Does anyone remember the history? What I'm questioning is why GETF
specifies the the use of EQ as opposed to EQL and/or why there is no
:test keyword argument. It makes some historical sense for GET to be EQ
based but GETF is "new school".
-- Jeff Barnett
Tim Bradshaw
It's being compatible with GET - all the property list functions use
EQ.
--tim
Kent M Pitman
Short Form:
Well, new school or old school, it was nice to describe abstractly
that the relation was (defun get (x y) (getf (plist x) y)).
So to have them do something utterly different would have been not so good.
Long Form:
Searching my memory, I was first thinking this was because of the Lisp
Machine... but I think the decision has to be seen in two parts. Some
of it is due to the LispM (the name and semantics of GETF) and some is
not due to LispM (the EQ/EQL default issue)... I think.
GETF was, on the LispM, a generalization of GET. I'm not sure which was
defined in terms of the other. But at that point, it wasn't super-general
with all those options. It was just GET with other args, and it tapped
into a long history of documented use.
The significance of it being GET at the heart of things, and certainly
of other things like MEMQ and ASSQ (originally, MEMQ and ASSQ were
EQ-basd, while MEMBER and ASSOC were EQUAL-based, and only later in CL
did it get generalized further).
But while you might imagine a desire to favor them, they were already
favored since all fixnums and chars were interned, so EQL and EQ did
pretty much the same on the LispM. Whether EQL or EQ were used as the
default hardly mattered.
EQ vs EQL was an abstraction invented for stock hardware to paper over
issues the hardware wasn't giving help with. Interlisp, which was a
whole different branch of evolution from a long time back, had made a
similar decision to have an EQP or some such operation, I believe.
Maybe in the Interlisp D-Machines (their brand of Lispms) they had
confronted this same issue, I don't know.
But regardless, at that time, there was still immense concern (and you
have to put into context the rampant concern about design based on
"unproven concepts", which was very real) about whether that last
little bit of speed you could get from being able to assume native
operations. We're talking machines with instruction times measured
often in milliseconds, and time-shared on top of that, so these things
mattered a great deal.
We (the Lisp community) were already heavily beaten up by other
languages for speed issues, for being interpreted-only (not that we
were, but no one was stopped by that), etc. And it was assumed that
every point of "flexibility" came at a speed cost and was a potential
culprit in that war.
Even during the design of CL, it was seriously discussed, and I think
I at least soemtimes if not always sided with, the idea of eliminating
the distinction and just saying EQL was the primitive (thus allowing
EQL to be renamed EQ). This discussion was mixed up, too, with the
question of whether a FIXNUM datatype was appropriate; I didn't want
that either, because it seemed to me it had no portable meaning (as EQ
seemed to have no portable meaning). It was made clear to me that this
was a price of acceptance of a substantial part of the community, who
wanted to continue to program as if they could access every last cycle
of the underlying machine.
There were not many users focused on porting, which of course is
because programs were not known to EVER port, and so the community had
absorbed that cost from the outset. The benefits of portability had
not been seen and were quite abstract. (The contrasting tension was
that the whole reason for CL to exist was so ARPA could port pieces of
technology developed at one site to run on another, so to be
successful CL had to at least promise to overcome the disinterest in
seriously addressing portability concerns.)
Of course, everyone supports portability, they just didn't at the time
support the price of it. It's like supporting the environment
... people say they're interested until the find it interferes with
other things--then it becomes not a "support" issue but a "priority"
issue. And in the case of portability, it took years (probably until
about 2 years after CLTL, when people started to try to port programs
and saw the failures after being promised it would work only to find
it didn't) for people to appreciate the issue (its need and its
practice) well enough to respond. The 1986 meeting of the CLTL design
committee + its newborn user community at Monterrey that year was
push came to shove, and it was clear that the use community was changing
and needed something ANSI-like to help avoid fist-fights because there
was (a) a big need for change and (b) no way to mediate that.
(It's an artifact of the time, though, that they needed mediation. It
was at that time too expensive for people to take such matters into
their own hands technologically. Since then, it's easier for
disaffected parties to just move on and provide other alternatives
without coercing the rest of the user community to do what perhaps
they don't want or need... which is why I don't think a "second
constitutional convention" of ANSI CL is needed.)
Please don't take the above as gospel. I didn't research it carefully
and I'm just recounting the parts I remember. But maybe it will spur
someone who has other info to correct me in places, and in the meanwhile
what it really offers you is a sense of "generally how these things go"
even if the details are off in some small way here and there.
Jeff Barnett
-- Jeff Barnett
Rainer Joswig
Jeff Barnett <jbb...@ca.rr.com> wrote:
Jeff, your posting came here as HTML code. You might want to
stick to plain text while posting to comp.lang.lisp .
I think you can't assume that Usenet client programs now
will do HTML rendering. Probably there is an option
in your client program, where you can switch HTML off?
Regards,
Rainer Joswig
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Kent M Pitman wrote:
> <blockquote cite="miduy7k2...@nhplace.com" type="cite">
> <pre wrap="">Tim Bradshaw <a class="moz-txt-link-rfc2396E" href="mailto:tfb+g...@tfeb.org"><tfb+g...@tfeb.org></a> writes:
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">On May 6, 7:28 am, Jeff Barnett <a class="moz-txt-link-rfc2396E" href="mailto:jbb...@ca.rr.com"><jbb...@ca.rr.com></a> wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">I don't remember the discussion (or the motivation) for the GETF spec.
> Does anyone remember the history? What I'm questioning is why GETF
> specifies the the use of EQ as opposed to EQL and/or why there is no
> :test keyword argument. It makes some historical sense for GET to be EQ
> based but GETF is "new school".
> </pre>
> </blockquote>
> <pre wrap="">It's being compatible with GET - all the property list functions use
> EQ.
> </pre>
> </blockquote>
> <pre wrap=""><!---->
> </pre>
> </blockquote>
> Thank you for the informative reply. I used the old Symbolics quite a
> bit and kibitzed the standards activity on the mail list group that was
> established way back when. Recently, I was writing some code, using
> Allegro, that I wanted to be portable. When I happened to glance at the
> GETF documentation, I was surprised. GET (as opposed to GETF) is used
> by system providers for all sorts of things and EQ tests are fine since
> the property names are usually symbols in system-builder packages to
> keep them out of the users' hair. On the other hand, GETF seems the
> ideal quick-and-dirty to implement sparse arrays (nested for multiple
> dimensions) and other such items. Hash tables seem to be too "heavy"
> for such uses. If assoc and its assoc-iates had a setf methods, there
> would be a first class facility in Lisp. Since they don't, the burden
> would appear to fall on GETF but its inadequate for integer (and
> character) keys. Once again, thanks for the memories.<br>
> <br>
> -- Jeff Barnett<br>
> </body>
> </html>
Kent M Pitman
> If assoc and its assoc-iates had a setf methods, there
> would be a first class facility in Lisp.
They're possible to write, of course.
Nothing keeps you from shadowing ASSOC and then adding setf methods to the
shadowed versions. I do that for my code.
Tim Bradshaw
>
> Please don't take the above as gospel. I didn't research it carefully
> and I'm just recounting the parts I remember. But maybe it will spur
> someone who has other info to correct me in places, and in the meanwhile
> what it really offers you is a sense of "generally how these things go"
> even if the details are off in some small way here and there.
I bought my copy of CLtL second hand during a trip to the east coast
of the US in the late 80s. I found it in a curious little bookshop
whose owner was, perhaps, a little more strange and unpleasant than
the owners of second-hand bookshops usually are. I was only learning
Lisp at that time, and perhaps did not realise the significance of
what I'd found.
The copy was battered and heavily annotated in various hands. The
most important thing I did not discover until my return to the UK - to
Cambridge, coincidentally. Between two pages were a couple of folded
sheets of fan-fold paper, with part of a listing. It was DEC
assembler, although some of the mnemonics had rather odd names, and
was, perhaps, part of the listing of a version of TECO.
There was writing on the reverse, which seemed to be some kind of
entry in a journal. I'll give it here as best I remember it. I feel
it may bear on the GETF issue.
----
Cambridge, 5/21/77. I saw them again last night, in the lab. Three of
them, perhaps four. The same as before? They are not [several words
heavily scored through]. One - the leader? - larger than the others,
ten[elided] indescribable. Same smell. Hard to make out what they were
saying, voices somehow *thick*. Talking about something called "the
chetef device"? CH like loch. What is it they are planning?
Something about sowing confusion in the minds of the weakest to open a
door - what kind of door?
5/22/77. They were there again. More clear this time. Number still
seems to vary somehow: don't understand, perhaps [elided]? The leader
was instructing the others. They seem to plan a new language (new
dialect?), which will somehow contain or enable this "chetef device".
And this device will open something. But what? Discussion of
"vessels" - ships? Mention of LISP: is it a new dialect of LISP they
are planning?
5/23/77. Much clearer. Perhaps too clear. They ARE USING US TO
CREATE A DOOR THROUGH WHICH [elided]. The language contains subtle
inconsistencies which will destroy the minds of those they call "pure
ones" or "weak ones" and they will occupy the husk remaining, before
[elided]. Terrible fate for [elided]. S[unreadable]eme, surely this
can not be part of their plan?
[The rest of the document is mostly unreadable: some fragments I could
decipher.]
THEY KNOW MY NAME! [illegible] one of the vessels. How can I escape?
[illegible] not "chetef", "getf" [elided] can this mean?
[Several lines crossed out.]
They are coming. I can see them. Even with my eyes closed I can see
them. I must prevent this, I will not be [illegible]. No. NO. They
will not [illegible]. Resist. My name. My name is [illegible] My
name ... oh, what does it matter who I was?
[Some partly-formed letters followed, and a curious, greenish stain.]
----
Unfortunately I no longer have the book: I remember it had several
pages torn out, and some of the annotations were, frankly,
disturbing. I kept the paper for longer, but the nightmares, even
during the day, became too much, and I burnt it.
Rob St. Amant
> I bought my copy of CLtL second hand during a trip to the east coast
> of the US in the late 80s. I found it in a curious little bookshop
> whose owner was, perhaps, a little more strange and unpleasant than
> the owners of second-hand bookshops usually are. I was only learning
> Lisp at that time, and perhaps did not realise the significance of
> what I'd found.
(Great pastiche snipped)
That was inspired, and very funny.