Compilation implications

[Jon L White <jonl@lucid.com>]

This somewhat long msg has questions aobut two issues in it:
    (A) "Reconstructor" functions for instances
    (B) References to classes "by name"
Partly I would like an answer to them to aid in development at Lucid,
and partly to help resolve lingering issues in the CL-Compiler's work
on quoted constants.


              (A) "Reconstructor" functions for instances

We at Lucid are getting more and more requests for a coherent "Reconstructor"
protocol (well, they are usually couched in ill-advised terms about making
FASLOUT user-extensible, but we've already seen this issue before).  Does 
anyone have any plans to work on this problem?  Didn't someone recently
say that Symbolics has some possibly-private Reconstructor capability?
What is the feeling about the Symbolics facility  (I don't know anything
about it).

One might ask, "How do ``instances'' come to the attention of FASLOUT?"
They can appear as a quoted constant; hence, Cris Perdue's query:
    Date: Mon, 14 Nov 88 11:54:29 PST
    From: cperdue@Sun.COM (Cris Perdue)
    To: cl-object-oriented-programming@sail.stanford.edu
    Subject: Standard-objects in quoted constants
to which Moon replied later that day about the need for a reconstructor
protocol.  I should think it rare for quoted instances to appear directly
in code files.  But there are some important exceptions that, indirectly,
introduce "constants" into a file; for example, the use of #. to emulate 
a FASDMP facility; and also macro-generated code that produces otherwise
unREADable forms.  If the semantics of DEFCONSTANT were more "hard-wired",
then it too would be such an exception.  ["hard-wired" means that the value
at run time is that obtained by evaluating the defconstant form at compile 
time, rather than by evaluating the form at load time; it would mean that
(defconstant foo (bar)) is similar to (defconstant foo (quote #.(bar))).]


Possibly, EQL specializers could raise this question.  Upon re-reading, 
the language of 88-002R now seems a bit vague to me, and possibly open 
to misinterpretation, as to just when an EQL parameter specializer form 
is evaluated.  Consider the similarity with DEFCONSTANT.  The language 
in CLtL about DEFCONSTANT seems to imply, to most people, that the runtime 
environment ought to have a special variable that holds the "constant" 
value  (references to which are allowed to be "snapped" in compiled code);
and that the value of this variable is set at load time, when the defining 
form's "form" is evaluated, just like it would be for defparameter.  [Hence 
DEFCONSTANT doesn't define a compile-time constant in the same way that 
conventional language compilers do.]  The various implementations I've 
looked at so far seem to do it this way -- they do an evaluation at load 
time (typically, by executing a "thunk") to produce the constant's value. 

The language of 88-002R doesn't seem to rule out either way of obtaining 
the "object"-- producing a thunk or producing a compile-time constant.
The only relevant difference is that it prescribed the evaluation to be 
done in the lexical environment of the defining form, which for 
COMPILE-FILE simply means that the "thunk" is compiled in that lexical 
environment.  But has anyone wanted the more "hardwired" version?



             (B) References to classes "by name"

The analogy between FIND-PACKAGE and FIND-CLASS suggests that class 
objects are in the same "database" category as packages.  Shouldn't
they be referenced "by name" in compiled file?   Lucid has been fasl'ing 
out packages for some time merely "by reference"; the culmination of the 
CL-Compiler's deliberations on "quoted constants in compiled files" seems 
to be that this is the only reasonable meaning for reference to a "quoted
package".  Are there any other implementations that do otherwise for
"quoted" classes?  

I realize this may pose some ordering constraints on the executions in a 
file, if the compiled version is to operate correctly -- i.e., classes might
have to be defined before the use of any constant that "names" that class.  
Such constraints may not be as feasible as they are in the package world 
(Indeed, some folks even dislike the package ordering constraints!).  Can 
a forward-reference, "placeholder" be substituted for a class that hasn't
yet been defined, but is referenced by a quoted constant?



-- JonL --