I am trying to make my code CLTL2-compatible, and eliminate the
warnings that it generates in Allegro 4.2beta. For example, when
I try to compile a file, I get the following messages:
; --- Compiling file /afs/cs/user/amickish/gesture/gestureinter.lisp ---
; While compiling (:TOP-LEVEL-FORM "gestureinter.lisp" 1):
Warning: compile-file found "EXPORT" at the top-level -- see the
documentation for comp:*cltl1-compile-file-toplevel-compatibility-p*
; While compiling (:TOP-LEVEL-FORM "gestureinter.lisp" 12):
Warning: compile-file found "PROCLAIM" at the top-level -- see the
documentation for comp:*cltl1-compile-file-toplevel-compatibility-p*
The offending code is at the top of the file:
(in-package "INTERACTORS")
(export '(gesture-interactor gest-classifier-convert))
(proclaim '(special Gesture-Interactor))
(defun Gesture-Interactor-Initialize (new-Gesture-schema)
...)
What is the standard way that I am supposed to change my EXPORT
and PROCLAIM instructions to eliminate the warning? The Allegro
4.1 docs say that they need to be wrapped in an eval-when, but
this seems awkward.
Furthermore, what is the "right" way to use MAKE-PACKAGE,
IN-PACKAGE and DEFPACKAGE? Where do the :use and :nicknames
keywords go? If there are multiple files participating in a single
package, what should be at the top of each file?
For example, can we just put DEFPACKAGE everywhere? Is there any
reason that DEFPACKAGE should not be used in many different files
that each export a few symbols from the same package?
Thanks for your advice,
--Andrew Mickish
In article <··················@andrew.cmu.edu>, Andrew Newell Mickish <·····@andrew.cmu.edu> writes:
> I am trying to make my code CLTL2-compatible, and eliminate the
> warnings that it generates in Allegro 4.2beta. For example, when
> I try to compile a file, I get the following messages:
> ; --- Compiling file /afs/cs/user/amickish/gesture/gestureinter.lisp ---
> ; While compiling (:TOP-LEVEL-FORM "gestureinter.lisp" 1):
> Warning: compile-file found "EXPORT" at the top-level -- see the
> documentation for comp:*cltl1-compile-file-toplevel-compatibility-p*
> The offending code is at the top of the file:
> (in-package "INTERACTORS")
> (export '(gesture-interactor gest-classifier-convert))
> (proclaim '(special Gesture-Interactor))
Did you read the documentation for the variable, as the compiler suggests?
It should explain of this to you, or at worst give you references to the
relevant sections in CLtL2.
> What is the standard way that I am supposed to change my EXPORT
> and PROCLAIM instructions to eliminate the warning? The Allegro
> 4.1 docs say that they need to be wrapped in an eval-when, but
> this seems awkward.
I'm finding this difficult to follow. You get warnings, you're offered an
explanation in the documentation, you have the suggested fix (eval-when), and
still you're unhappy. Use eval-when!
> Furthermore, what is the "right" way to use MAKE-PACKAGE,
> IN-PACKAGE and DEFPACKAGE? Where do the :use and :nicknames
> keywords go? If there are multiple files participating in a single
> package, what should be at the top of each file?
DEFPACKAGE is preferred to MAKE-PACKAGE.
> For example, can we just put DEFPACKAGE everywhere? Is there any
> reason that DEFPACKAGE should not be used in many different files
> that each export a few symbols from the same package?
You should only use DEFPACKAGE once for a given package. Use IN-PACKAGE
after that, and explicitly EXPORT the new symbols.
-- Don
P.S. I suspect most of your questions would be answered, with explanations
and justifications, if you read Steele's "Common Lisp: The Language, Second
Edition". All of this is covered there.
--
Don Geddis (······@CS.Stanford.Edu)
Eat right, exercise regularly, die anyway.
In article <··················@andrew.cmu.edu> Andrew Newell Mickish <·····@andrew.cmu.edu> writes:
>What is the standard way that I am supposed to change my EXPORT
>and PROCLAIM instructions to eliminate the warning? The Allegro
>4.1 docs say that they need to be wrapped in an eval-when, but
>this seems awkward.
The non-awkward solution is to use macros whose expansions make use of
EVAL-WHEN. In particular, DEFPACKAGE will do this for the EXPORTs, and
DECLAIM is the macro variant of PROCLAIM.
>Furthermore, what is the "right" way to use MAKE-PACKAGE,
>IN-PACKAGE and DEFPACKAGE? Where do the :use and :nicknames
>keywords go? If there are multiple files participating in a single
>package, what should be at the top of each file?
You should put all the package options in DEFPACKAGE. It will do the
MAKE-PACKAGE for you. At the top of each file should just be a simple
(IN-PACKAGE "package") call. The CLtL2/dpANS version of IN-PACKAGE doesn't
accept any options.
>For example, can we just put DEFPACKAGE everywhere? Is there any
>reason that DEFPACKAGE should not be used in many different files
>that each export a few symbols from the same package?
If you execute a DEFPACKAGE for a package that already exists, it must be
consistent with the state of the package. If you put a DEFPACKAGE in many
different files, this means that they must all be identical. You can't
have different DEFPACKAGE forms importing and exporting different sets of
symbols.
Therefore, the correct solution is to put it in a single file which is
always loaded before compiling or loading any other files that refer to the
package. This DEFPACKAGE form is effectively the definition of your
package's interface to the rest of the environment (like module definitions
in MODULA, class declarations in many OO languages, header files in C,
etc.). It shouldn't be changing frequently if you practice good design
methodologies.
In article <··················@telecaster.think.com> Barry Margolin,
······@think.com writes:
> If you execute a DEFPACKAGE for a package that already exists, it must
be
> consistent with the state of the package. If you put a DEFPACKAGE in
many
> different files, this means that they must all be identical. You can't
> have different DEFPACKAGE forms importing and exporting different sets
of
> symbols.
>
The CLtL II description of DEFPACKAGE explicitly says that DEFPACKAGE on
an existing package should "modify it". Now, different implementations
have different opinions on what "modify" means. For instance this is the
case for the (:USE ...) option. Most implementations let the USE-option
operate exactly like a call to USE-PACKAGE (i.e., the parameters to :USE
are added to the USE-list of the package), but some implementations have
a different interpretation: The USE-list of the package is completely
replaced by the arguments to :USE. At least in MCL 2.0 this is the case.
Which solution is the better one?
Is any of them wrong?
I personally think CLtL II is open to both interpretations, although the
standard solution may be the most "obvious". The MCL solution seems
"cleaner" to me, though. But it sometimes may make it a headache porting
large programs to MCL (I know of an actual case with LOTS of redefining
DEFPACKAGEs).
________________________________________________________________________
Espen J. Vestre, ·····@coli.uni-sb.de
Universit�t des Saarlandes,
Computerlinguistik, Geb�ude 17.2
Postfach 1150, tel. +49 (681) 302 4501
D-66041 SAARBR�CKEN, Germany fax. +49 (681) 302 4351
In article <············@coli-gate.coli.uni-sb.de> Espen J. Vestre <·····@coli.uni-sb.de> writes:
>The CLtL II description of DEFPACKAGE explicitly says that DEFPACKAGE on
>an existing package should "modify it". Now, different implementations
>have different opinions on what "modify" means. For instance this is the
>case for the (:USE ...) option. Most implementations let the USE-option
>operate exactly like a call to USE-PACKAGE (i.e., the parameters to :USE
>are added to the USE-list of the package), but some implementations have
>a different interpretation: The USE-list of the package is completely
>replaced by the arguments to :USE. At least in MCL 2.0 this is the case.
>
>Which solution is the better one?
>Is any of them wrong?
Here's what version 12.24 of the dpANS (the one that was in last year's
public review) says:
If the new definition is at variance with the current state of that
\term{package}, the consequences are undefined; an implementation
might choose to modify the existing \term{package} to reflect the
new definition.
In other words, either behavior is allowed, as would any other result
(deleting the package, exiting Lisp, core dumping, etc.).
There was a public review comment asking for clarification on what it means
for the definition to be "at variance". I don't remember offhand what our
response was.
>I personally think CLtL II is open to both interpretations, although the
>standard solution may be the most "obvious". The MCL solution seems
>"cleaner" to me, though. But it sometimes may make it a headache porting
>large programs to MCL (I know of an actual case with LOTS of redefining
>DEFPACKAGEs).
Since redefining DEFPACKAGEs are not defined by the language, portability
problems are to be expected. Find all the DEFPACKAGEs for the same package
and merge them into one.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar