[Ecls-list] symbol-macro usage

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> Your problem is related to a similar one, namely the use of DEFPACKAGE forms
> in compiled files. It is commonly agreed that DEFPACKAGE (and by that
> rational other package changing forms) should be compiled in separate files,
> precisely because otherwise there are problems like the one you find.
> 

Hmm, maybe the file changed, but I do not see DEFPACKAGE in

http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/integration/common.lisp

> What is the problem then? The ANSI specification says that COMPILE-FILE must
> create a file that is used by the loader in a two-step way: reconstruct
> literal objects and execute forms. The order in which the object
> reconstruction happens is unclear and not specified. ECL, GCL and probably
> other lisps create the objects before ANY form is executed. Then any use of
> those objects is done by reference to the created objects.
>
> Object creation must happen by a notion of "similarity" :
> http://www.lispworks.com/documentation/HyperSpec/Body/03_bdbb.htm For
> instance if the compiler finds a symbol hu.dwim.common::in-package in the
> compiled file, it will look up at load time an object with the same name
> IN-PACKAGE that is accessible from that package.
> 
> Note that the specification says "at load time" but it does not says at the
> time the form is executed.

HypeSpec says about LOAD:

: To load a file is to treat its contents as code and execute that code.
: The file may contain source code or compiled code.
:
: A file containing source code is called a source file. Loading a source
: file is accomplished essentially by sequentially reading[2] the forms in
: the file, evaluating each immediately after it is read.

: A file containing compiled code is called a compiled file. Loading a
: compiled file is similar to loading a source file, except that the file
: does not contain text but rather an implementation-dependent
: representation of pre-digested expressions created by the compiler.

AFAICS this implies seqential treatment of top-level form, unless
some other parts gives explicit permission for more loose
interpretation.  In particular one can expect side effect on package
system to take place before "similarity" is used to restore object
from next top level form.

> It is explicitely vague about when objects are
> created. Otherwise it would impose inefficient object creation mechanisms,
> such as lookup by name for *every* symbol in the file.
>

Well, surely you need to lookup every _symbol_ in the file: if at
compile time symbols are different you expect to get different
symbols after loading.  If you mean lookup at every occurence of
a symbol, then there is no such need: just keep translation table
during loading and do lookup for first occurence (more precisely
before evaluating toplevel form with the first occurence).  
 

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl