Re: Packages: where is the beef ?

[simon@lia.di.epfl.ch (Simon Leinen)]

>      [** 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???

ASSERT and CLASS are symbols that are intended to be used by users
(programmers in this case).  It is a *feature* that they have
intuitive names.  It is also a problem that X3J13 defines 973 of these
symbols, and nobody can be expected to know all of them.  Allegro's
package-locking is another *feature* that prevents you from breaking
the system because you don't know all of them.

> 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.

Common Lisp's way to handle *internal* symbols is more elegant - they
reside in other packages (like EXCL or LUCID or CLOS-INTERNALS) and
are usually not seen at all.  No need for underscores.

External symbols in the C libraries have very much the same problem
than the symbols that are exported from the COMMON-LISP package.  If
you define a function named "socket" in your C program, then a call to
"getpwnam" somewhere else may fail because the implementation of
getpwnam() might call socket() and expects a different behaviour.  C's
workaround for this problem is to choose obnoxious names for library
functions, or use separate libraries, much like there are separate
packages in CL.

> 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.

Completely unnecessary - *everything* you can do with funny naming
conventions you can do (better) with packages.

> 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.

That's not been X3J13's task.  I don't think friendliness to students
would have been a reasonable goal for a CL standard - Scheme fills
this gap quite nicely.  If you want a "simple" CL for students you can

	(defpackage "AI-6001-LISP"
	  (:use "COMMON-LISP")
	  (:export "CAR" "CDR"^H^H^H^H^H^H^H^H^H^HFIRST" "REST" "CONS"
	   "ATOM" "IF" "DEFUN"
	  ;; <add the names of your favourite "important" symbols here>
	  ))

	(defpackage "AI-6001-LISP-USER"
	  (:use "AI-6001-LISP"))

and set up your students' Lisp to start up in the AI-6001-LISP-USER
package.  The decision of which symbols are "important" is just too
dependent on the observer to be standardised.

I agree that parts of the language could have been moved to different
packages, for example CLOS or the condition system, but on the other
hand everything is integrated so well and I wouldn't like to see
subsystems like the two mentioned ones under-used because they are
somehow regarded as "optional" packages.  Common Lisp chooses to
provide the whole language in one package and let *you* create
restricted packages rather than providing a zillion of packages that
you can then assemble.

>      [** 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'.

Of course this works.  It is only that very few people know how or
dare to use shadow.  I know that because in our AI lab people rarely
even use packages at all, and we're a 100% Common Lisp shop.  What a
shame.

The package system is your friend.
Allegro's package locking is your friend, too.
-- 
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
IN-Ecublens
CH-1015 Lausanne
Tel.: +41-21-693-5277