[Ecls-list] symbol-macro usage

[Juan Jose Garcia-Ripoll]

On Sat, Feb 13, 2010 at 3:23 PM, Waldek Hebisch <hebisch at math.uni.wroc.pl>wrote:

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

I did not say that DEFPACKAGE was there, but that the issues are related.

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


This implies sequential EXECUTION of toplevel forms. It does not imply that
the constants referenced in the toplevel forms have to be created
sequentially. There is a difference between the forms that are executed and
the content of those forms. The predigested forms do contain all constants
and objects which are needed. In particular, symbols. The previous paragraph
only imposes that the forms are executed sequentally, not WHEN the objects
that constitute those forms are created.

What you are asking is something similar to changing the readtable between
two forms which are sequentially read from a source file. This can be done
in a source file but not in a compiled file. Or would you expect it to
behave the same?

Furthermore, the same expectations that motivate this discussion would also
lead newbies to think that if I compile function
   (defun foo (x)  'my-changing-package:some-symbol)
the output should change if I decide to
shadow my-changing-package:some-symbol and replace it with some other
reference.

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


Yes, we do lookup objects but you are imposing that references to objects
must be created every time they are used, because previous forms may change
the similarity relation. That means for instance that object creation must
happen as the binary file is executed, maybe before each toplevel form, that
constant coalescion is not possible, that we would have to insert explicit C
statements to create objects instead of a using global table, and other
things that enlarge code and make it less efficient.

I think ECL is consistent in its behavior: all constants are created at load
time and shared by the whole compiled file. This includes symbols. If a
constant must depend on the precise order in which toplevel forms are
executed then it is not a constant and should be replaced with a variable or
some other lisp expression.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100213/185e2eb3/attachment.html>