Re: Packages: where is the beef ?

[tony@brc.uconn.edu (Tony Guzzi (Staff))]

>>> From: ks@cs.tut.fi (Kari Systa) Thu, 3 Sep 1992 14:41:51 GMT
>>> Subject: Packages: where is the beef ?

>>> ..... packages are name scopes in which I can define what ever symbols
>>> I want to without having conflicts.  Unfortunately, it is NOT true in
>>> Common Lisp (at least not in Allegro Common Lisp).  I have faced this
>>> problem several times in the past, but today when I upgraded to version
>>> 4.1 (from 4.0.1) noticed new flavors in this rotten beef.
>>>
>>> First I tried to make my own structure named 'assert' in my own private
>>> ... problems because of the new package locking scheme.  After RTFM I
>>> found that I must set 'excl:*enable-package-loking-errors*' to nil. .....
			:
			:
>>> Next error message is:
>>>  Error: validate-metaclass-change forbids changing the class of
>>>         #<standard-class class @ #x4298be> to
>>>         #<standard-class structure-class @ #x41fa66>
>>>    [condition type: program-error]
>>> I don't (yet) know how to work around this. I guess the lisp does not like
>>> the idea of having a structure named 'class' even in my own package.
			:
			:
>>> % This article represents my personal views.
>>> % Kari Systa, Tampere Univ. Technology, Box 553, 33101 Tampere, Finland
>>> % work: +358 31 162585      fax: +358 31 162913      home: +358 31 177412
>>> % Internet: ks@cs.tut.fi    X.400: C=fi ADMD=fumail O=TUT OU=CS S=ks
>>> -- 

The package 'problem' is a well known, "pain in the butt" problem.  A lot
of the problem has to do with implementors picking too generic a system to
represent system functions (like the 'CLASS' symbol for CLOS) and then
exporting it to most (if not all) other packages.  In the past, a '(defstruct
class ....)' or '(defstruct tree ....)' would crash or hang ACL.  It seems
the I/O subsystem is based on CLOS and needs that package (along with its
symbols) which is why, I guess, all packages contain CLOS's symbols
(including the CLASS symbol).  The locking mechanism looks like a good idea,
but ....
     [** begin flame***]
with Artifical Intelligence-oriented people (like myself) using lisp very
often (and defining classes and trees in thier work all the time), the choice
of system-important symbols like these was highly inappropriate.  What were
the people in the CommonLisp standard committee (X3J13) thinking of???  I
think a better decision would have been to use 'unusual' symbols (e.g.
'_TREE_' or '#_TREE_#' in the Top-Level package or '_##CLASS##_' or '#SSALC#'
in CLOS instead of just 'TREE' or 'CLASS') for highly important symbols to
minimize the possibility that a user will accidentally re-define them.  This
is the type of thing many compilers (C, FORTRAN, Pascal) do to safeguard
internal functions (the most common technique being to add a '_' to the
beginning and/or end of the symbol/variable/function_name.  While the
meanings may not be immediately apparant, I'm sure a derivation 'algorithm'
can be found where, once known, they are easily recognized and understood
(e.g. '_##<symbol spelled backwards>##_').  If we're not supposed to change
them (unless we know what we're doing), why make them _easily_ accessible to
the common user.  X3J13 needs to redefine a few _important_ symbols, I think,
to make them less susceptible to user-'munging' yet still accessible if in
the hands of knowledgable (i.e. 'know what they're doing') programmers.
     [** end flame***]

The only solution I've found is to shadow the symbols in the package.  I
use 4.0.1 and have to guess as which system symbols are being redefined.
It seems, with 4.1 tells you which one are redefined, things should make
shadowing them easier.  I'm courious, are you shadowing these symbols and
still getting the error from 'validate-metaclass-change'?  I'd assume ACL
wouldn't give you the error if you were shadowing them or is ACL 'rotten'
(as you put it) in this way too?  If you're shadowing and still coming up
with the error message, then things are 'rotten'.

-- Tony Guzzi
   (graduate student)

 Internet:		| U.S. Mail:
    tony@brc.uconn.edu  |    University of Connecticut
			|    U-155, Dept. of Computer Science & Engineering
			|    260 Glenbrook Road
			|    Storrs, CT  06269-3155
			|    USA