[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]



The idea has obvious intuitive appeal, since people tend to think of
exporting definitions rather than names.  Unfortunately, I think that
there is likely to be some messy semantics due to name resolution
happening at read time and the implicit package manipulation happening
later on.  The semantics of package manipulation with respect to
compile-file/load is currently not defined.  [Except perhaps in some
vague language that suggests the semantics of loading the source are
preserved, which is clearly wrong.]  It is certainly naive to suppose
that a macro can expand into arbirary package manipulation code and
"the right thing" will happen.

I think that exporting symbols from the current package happens to be
safe as long as all the code in a file is restricted to one package,
but I certainly don't want to have to figure out which of all possible
kinds of package manipulation will break what possible reasonable
compiler organizations.

You should also be careful that you aren't thinking of this issue in
terms of "top-level defining forms", since I am convinced that the
notion of a "top-level form" is semantically bankrupt.  Although some
forms are most often used at "top-level" (however defined), the
semantics of those forms are a result of its evaluation, and a form can
be evaluated anywhere.  Consider the semantics of:
  (if <whatever>
      (defun-exported foo ...))

Consider the possible range of implementations such as "compilers" and
"interpreters".  Is Foo {always | never | sometimes} exported at 
{read | macroexpand | compile | load | run} time?

I currently favor requiring all package manipulation to be done at the
head of the file.  This has the advantage that it allows compilers and
editors to find all stuff pertinent to read-time semantics without
having to go through the motions of compiling the entire file.

Of course, it would be possible to have an automatic exporting feature
without allowing users to have package-hacking macros.

  Rob