I was surprised to find that, in one Lisp implementation, calling INTERN on
a symbol doesn't signal an error.
The HyperSpec section on INTERN indicates INTERN's first parameter is a
string, but doesn't say anything directly about other data types.
Can this be considered a bug in the implementation in question, or just an
extension?
More detail:
Section on INTERN:
<http://www.harlequin.com/education/books/HyperSpec/Body/fun_intern.html>
--
Will Fitzgerald
Neodesic Corporation
In article <··········@news.net-link.net>,
Will Fitzgerald <··········@neodesic.com> wrote:
>I was surprised to find that, in one Lisp implementation, calling INTERN on
>a symbol doesn't signal an error.
>
>The HyperSpec section on INTERN indicates INTERN's first parameter is a
>string, but doesn't say anything directly about other data types.
>
>Can this be considered a bug in the implementation in question, or just an
>extension?
An extension. The description of INTERN doesn't say that it must signal an
error for other types, so the consequences are undefined and the
implementation can do whatever it wants. If it treats it as if you'd done
(intern (symbol-name 'symbol)), that's reasonable. If it were to treat it
as if you'd done (intern (reverse (symbol-name 'symbol))), it wouldn't be
violating the standard either.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
* "Will Fitzgerald" <··········@neodesic.com>
| I was surprised to find that, in one Lisp implementation, calling INTERN on
| a symbol doesn't signal an error.
|
| The HyperSpec section on INTERN indicates INTERN's first parameter is a
| string, but doesn't say anything directly about other data types.
well, I was surprised to learn that INTERN does _not_ take a string
designator, like almost everything else that accepts strings as arguments.
#:Erik
--
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.
Erik Naggum <····@naggum.no> writes:
> * "Will Fitzgerald" <··········@neodesic.com>
> | I was surprised to find that, in one Lisp implementation, calling INTERN on
> | a symbol doesn't signal an error.
> |
> | The HyperSpec section on INTERN indicates INTERN's first parameter
> | is a string, but doesn't say anything directly about other data
> | types.
>
> well, I was surprised to learn that INTERN does _not_ take a
> string designator, like almost everything else that accepts
> strings as arguments.
My vague recollection is that maybe INTERN used to take a string or
symbol before the days of IMPORT, and that this led to lots of
disasters with people accidentally confusing (import 'foo) with
(intern "FOO"), which have very different semantics. My specific
recollection is that people accidentally interned a lot of keywords
into non-keyword packages.
Ok, I went back and looked it up and it reminded me of the problem,
which is even worse than I remembered: Maclisp *had* no strings so
only took symbols. If you gave it a symbol, it would look it up and
return the interned version and otherwise if it didn't exist would
intern it.
(Also, by the way, that the term "string designator" didn't exist
until fairly recently when I added it for the ANSI CL definition, so
the question of what would take "strings" or "string designators" was
not as crisp in the past as it is now; it used to be the question of
what "also takes symbols" which didn't make it as clear that there was
a missing argument type.)
Anyway, this led to lots of problems, which if memory serves me is why
the separate function IMPORT arose for the lispm. (Actually, I wasn't
involved in the lispm design discussions, but I my memory is of trying
to puzzle this out at the time IMPORT appeared on the lisp machine and
of concluding then that this was the reason. English offers no good
pithy terminology for distinguishing the conclusion of a remembrance
and the remembrance of a conclusion. Grrr.)
(This problem of INTERN/IMPORT is structurally analogous to the
problem created by IN-PACKAGE in the CLLT1 days, when it would both
demand-create or lookup packages. It was necessary to separate these
because the program errors that happened to people who sent it
incorrect data and got demand-creation were baffling. A separate
DEFPACKAGE and a reduced-functionality IN-PACKAGE was the solution...)
Now that there is a separate IMPORT function, it's not wholly
unreasonable to want to simplify the language definition by making
INTERN take a string designator. I wouldn't oppose the idea too
strongly. But I will predict that if you do this, you will be
answering questions from time to time about people calling IMPORT when
they wanted INTERN or vice versa. Both start with "I" and have about
the same length name. Both are about symbols, and in fact they
perform nearly the identical operation on symbols, differing only in a
very subtle way.
Personally, I think the practice of using symbols as string designators
is questionable in programs, much though I like it for some interactive
convenience. The problem is that it leaves garbage symbols all over the
place, and the presence of those symbols is program-detectable.
(Speaking only hypothetically: I *would* like a revision of the
language in which the class keyword was changed to be a subclass of
string instead of being a subclass of symbols, and in which every
symbol name became a keyword. In such a revision, it would be useful
and clean to use keywords as string designators, and in fact the
resulting symbol would have that very keyword as its name. This would
also make us of keyword arguments not require additional storage to store
both :foo and foo for every object, since :foo would be a part of every
foo, and in fact :foo would be a shared part of every x:foo and y:foo.
For a brief while in CLTL originally, keywords were on track to become
non-symbols--we didn't have time to do it for CLTL and thought it would
get fixed later. But for some reason it didn't come up in ANSI CL, or it
got lost. (I suppose I could check my notes.) I still think it's a
good idea. I would also turn &rest to :rest, etc. There is no need to
waste a perfectly good namespace of regular symbols when keywords would
work as well there... Ah, well. Enough language design for this one
parenthetical remark.)
Anyway, I guess my main point was that the omission of symbol as a
possible argument type to INTERN wasn't a simple oversight, nor is
"fixing" it as much of a no-brainer as it might seem. There are some
subtle issues afoot.