Newsgroups: comp.lang.lisp
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: GET / GETF warning.
Message-ID: <1991Apr26.212452.26837@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <641@zogwarg.etl.army.mil>
Date: Fri, 26 Apr 91 21:24:52 GMT

In article <641@zogwarg.etl.army.mil> hoey@zogwarg.etl.army.mil (Dan Hoey) writes:
>The fact that GET/GETF use EQ instead of EQL needs to be emphasized
>more.  Such as a remark that it is an error to use a number as an
>indicator in the property list.

Just this morning I happened to be reviewing the section of the draft ANSI
spec that includes GET, and I made precisely the same comment, so it should
make it into the standard.

Characters also can be EQL but not EQ, so they shouldn't be used as
indicators, either.

[Before anyone asks, the draft spec is not yet in any shape for
distribution outside X3J13.]

>It's all the worse that for many implementations EQL fixnums are EQ,
>so you don't see the bug until your problem gets into bignums.
>
>This might be a useful thing to put in the FAQ list, too.

I doubt that people frequently use non-symbols as indicators; people almost
always use symbols.  In general, it's bad programming practice to use any
global object as an indicator, because you might clash with another program
that makes the same mistake.  If you use symbols, they should be in your
own package (and watch out for inherited symbols -- don't do (setf (get
person 'car) 'datsun)); if you use lists, they should be constructed at
runtime rather than constants (because the compiler may coalesce similar
constant lists).
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
