[comp.lang.lisp] GET / GETF warning.

hoey@zogwarg.etl.army.mil (Dan Hoey) (04/26/91)

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.

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.

Dan

barmar@think.com (Barry Margolin) (04/27/91)

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

gumby@Cygnus.COM (David V. Wallace) (04/27/91)

   Date: 26 Apr 91 21:24:52 GMT
   From: barmar@think.com (Barry Margolin)

			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.

Whis is why I use arbitrary runtime data (eg (CONS NIL NIL) or
(make-symbol "Meaningful name")) as a tag whenever possible...

These days you might as well make a symbol; if you're concerned about
the storage overhead yu probably shouldn't use plists anyway.