marcuskammer/cl-sites
1
0
Fork 0
Code Activity
cl-sites/HyperSpec-7-0/HyperSpec/Issues/iss236_w.htm
Marcus Kammer 0f07a4353d Add hyperspec
2024-04-01 10:24:07 +02:00

367 lines
30 KiB
HTML
Raw Permalink Blame History

<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
<HTML>
<HEAD>
<TITLE>CLHS: Issue MAKE-LOAD-FORM-CONFUSION Writeup</TITLE>
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
<LINK REL=TOP HREF="../Front/index.htm">
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
<LINK REL=PREV HREF="../Issues/iss235_w.htm">
<LINK REL=UP HREF="../Issues/iss236.htm">
<LINK REL=NEXT HREF="../Issues/iss237_w.htm">
</HEAD>
<BODY>
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss235_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss236.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss237_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
<HR>
<H2>Issue MAKE-LOAD-FORM-CONFUSION Writeup</H2>
<PRE><B>Status:</B> Proposal REWRITE (version 8) accepted 12/91<P>
<B>Issue:</B> <A HREF="iss236.htm">MAKE-LOAD-FORM-CONFUSION</A><P>
Reference: Draft 9.126, <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> (p.9-30)<P>
Proposal <A HREF="iss215.htm">LOAD-OBJECTS:MAKE-LOAD-FORM</A> (Version 4)<P>
Proposal <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES:SPECIFY</A> (Version 10)<P>
Proposal COMPILE-ENVIRONMENT-CONSISTANCE:CLARIFY (Version 6)<P>
Issue CONFORMING-METHODS<P>
<B>Category:</B> Change<P>
<B>Edit History:</B> Version 1, 7/19/91, Kim Barrett<P>
Version 2, 7/25/91, Kim Barrett<P>
Version 3, 8/2/91, Kim Barrett<P>
Version 4, 8/18/91, Kim Barrett<P>
Version 5, 9/3/91, Kim Barrett (dangling &quot;conforming method&quot;)<P>
Version 6, 9/18/91, Kim Barrett (proposal REWRITE)<P>
Version 7, 9/25/91, Kim Barrett<P>
(proposal REWRITE-WITH-POSITIONALS, update Discussion &amp;etc,<P>
change &quot;same (<A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A>)&quot; to &quot;\term{same}&quot;, add &quot;Notes&quot;)<P>
Version 8, 9/25/91, Kim Barrett (Moon's comments, change bars)<P>
<P>
<B>Problem Description:<P>
</B><P>
The last paragraph of the <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> proposal inadvertently forbids<P>
implementations from providing methods for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> which are applicable<P>
to instances with metaclass <A REL=DEFINITION HREF="../Body/t_std_cl.htm#standard-class"><B>STANDARD-CLASS</B></A> or <A REL=DEFINITION HREF="../Body/t_stu_cl.htm#structure-class"><B>STRUCTURE-CLASS</B></A>.<P>
<P>
There was discussion about specifying that <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> metaobjects encountered as<P>
compiled constants should be handled by looking up the <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> by name at load<P>
time, but it appears that several mutually referencing issues may have all<P>
assumed that this would be dealt with by one of the others, with the result<P>
that nothing was actually specified for this situation.<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> and <A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> are functions that deal with<P>
forms, but violate the general principle that any function that manipulates<P>
forms must have access to the environment in which those forms are to be<P>
processed.<P>
<P>
<B>Proposal (MAKE-LOAD-FORM-CONFUSION:REWRITE):<P>
</B><P>
[Note: Lines beginning with &quot;-n-&quot; (where n is an integer) are not part of this<P>
proposal. These lines were taken verbatim from the passed <A HREF="iss215.htm">LOAD-OBJECTS</A><P>
proposal, and are present only as an aid to understanding some of the changes<P>
being made by this proposal by presenting both the original text and the<P>
corresponding rewritten description side by side. Lines beginning with &quot;+n+&quot;<P>
are part of the proposal, and are the proposed replacements for the<P>
corresponding &quot;-n-&quot; text. However, the absence of these change markers should<P>
not be taken to imply that the unmarked text is the same as the <A HREF="iss215.htm">LOAD-OBJECTS</A><P>
proposal or Draft 9.126.]<P>
<P>
1. Replace the specification of <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> with the following:<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> Standard Generic Function<P>
<P>
Syntax:<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> object &amp;optional environment<P>
<P>
Method Signatures:<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>make-load-form</B></A> (object <A REL=DEFINITION HREF="../Body/t_std_ob.htm#standard-object"><B>standard-object</B></A>) &amp;optional environment<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>make-load-form</B></A> (object <A REL=DEFINITION HREF="../Body/t_stu_ob.htm#structure-object"><B>structure-object</B></A>) &amp;optional environment<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>make-load-form</B></A> (object condition) &amp;optional environment<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>make-load-form</B></A> (object <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A>) &amp;optional environment<P>
<P>
Arguments:<P>
object -- an object.<P>
environment -- an environment object.<P>
<P>
Values:<P>
Value 1: Creation form.<P>
Value 2: Initialization form or not returned.<P>
<P>
Description:<P>
The generic function <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> creates and returns one or two<P>
forms, a creation form and an initialization form, that enable <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> to<P>
construct an object equivalent to \arg{object}. \arg{Environment} is<P>
the environment in which the forms will be processed.<P>
<P>
-1- <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> calls <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> on any object that is referenced as<P>
-1- a constant or as a self-evaluating form, if the object's metaclass is<P>
-1- <A REL=DEFINITION HREF="../Body/t_std_cl.htm#standard-class"><B>STANDARD-CLASS</B></A>, <A REL=DEFINITION HREF="../Body/t_stu_cl.htm#structure-class"><B>STRUCTURE-CLASS</B></A>, any user-defined metaclass (not a<P>
-1- subclass of <A REL=DEFINITION HREF="../Body/t_built_.htm#built-in-class"><B>BUILT-IN-CLASS</B></A>), or any of a possibly-empty<P>
-1- implementation-defined list of other metaclasses. <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> will<P>
-1- only call <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> once for any given object (compared with <A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A>)<P>
-1- within a single file.<P>
+1+ <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> calls <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> on any object that is referenced as a<P>
+1+ constant or as a self-evaluating form, if the object is a generalized<P>
+1+ instance of <A REL=DEFINITION HREF="../Body/t_std_ob.htm#standard-object"><B>STANDARD-OBJECT</B></A>, <A REL=DEFINITION HREF="../Body/t_stu_ob.htm#structure-object"><B>STRUCTURE-OBJECT</B></A>, <A REL=DEFINITION HREF="../Body/e_cnd.htm#condition"><B>CONDITION</B></A>, or any of a<P>
+1+ possibly empty implementation dependent list of other classes.<P>
+1+ <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> will only call <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> once for the \term{same}<P>
+1+ object within a single file.<P>
<P>
-2- It is valid for user programs to call <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> in other<P>
-2- circumstances, providing the argument's metaclass is not <A REL=DEFINITION HREF="../Body/t_built_.htm#built-in-class"><B>BUILT-IN-CLASS</B></A><P>
-2- or a subclass of <A REL=DEFINITION HREF="../Body/t_built_.htm#built-in-class"><B>BUILT-IN-CLASS</B></A>.<P>
+2+ Programmers may call <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> directly, providing \arg{object} is<P>
+2+ a generalized instance of one of the explicitly named classes listed<P>
+2+ previously.<P>
<P>
-3- <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> of an object of metaclass <A REL=DEFINITION HREF="../Body/t_std_cl.htm#standard-class"><B>STANDARD-CLASS</B></A> or<P>
-3- <A REL=DEFINITION HREF="../Body/t_stu_cl.htm#structure-class"><B>STRUCTURE-CLASS</B></A> for which no user-defined <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> is applicable signals<P>
-3- an error. It is valid to implement this either by defining default<P>
-3- methods on <A REL=DEFINITION HREF="../Body/t_std_ob.htm#standard-object"><B>STANDARD-OBJECT</B></A> and <A REL=DEFINITION HREF="../Body/t_stu_ob.htm#structure-object"><B>STRUCTURE-OBJECT</B></A> that signal an error<P>
-3- or by having no applicable <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> for those classes.<P>
+3+ The methods specialized on <A REL=DEFINITION HREF="../Body/t_std_ob.htm#standard-object"><B>STANDARD-OBJECT</B></A>, <A REL=DEFINITION HREF="../Body/t_stu_ob.htm#structure-object"><B>STRUCTURE-OBJECT</B></A>, and<P>
+3+ <A REL=DEFINITION HREF="../Body/e_cnd.htm#condition"><B>CONDITION</B></A> all signal an error of type <A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A>.<P>
<P>
The <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> specialized on <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>CLASS</B></A> returns a creation form using the name<P>
of the <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> if the <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> has a proper name in \arg{environment},<P>
signaling an error of type <A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A> if it does not have a proper name.<P>
Evaluation of the creation form uses the name to find the <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> with<P>
that name, as if by calling <A REL=DEFINITION HREF="../Body/f_find_c.htm#find-class"><B>FIND-CLASS</B></A>. If a <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> with that name has<P>
not been defined, then a <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> may be computed in an implementation<P>
defined manner. If a <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> cannot be returned as the result of<P>
evaluating the creation form, then an error of type <A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A> is signaled.<P>
<P>
Implementations may <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> additional methods specialized on system<P>
classes. It is implementation dependent whether calling <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A><P>
on a generalized instance of a \term{system class} signals an error or<P>
returns creation and initialization forms.<P>
<P>
Both implementations and programs may define additional<P>
\term{conforming methods} to extend the behavior of <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>.<P>
<P>
The creation form is a form that, when evaluated at \term{load time},<P>
should return an object that is equivalent to \arg{object}. The exact<P>
meaning of ``equivalent'' depends on the type of object and is up to<P>
the programmer who defines a <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>. See ``What can<P>
appear as a constant'' and ``Similarity as constants''.<P>
<P>
The initialization form is a form that, when evaluatated at \term{load<P>
time}, should perform further initialization of the object. The value<P>
returned by the initialization form is ignored. If <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A><P>
returns only one value, the initialization form is <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, which has no<P>
effect. If \arg{object} appears as a constant in the initialization<P>
form, at \term{load time} it will be replaced by the equivalent object<P>
constructed by the creation form; this is how the further<P>
initialization gains access to the object.<P>
<P>
-4- Both the creation form and the initialization form can contain<P>
-4- references to objects of user-defined types (defined precisely below).<P>
+4+ Both the creation and initialization forms may contain references to<P>
+4+ objects of any type which can be processed as a constant by<P>
+4+ <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>. However, there must not be any circular dependencies in<P>
creation forms. An example of a circular dependency is when the<P>
creation form for the object X contains a reference to the object Y,<P>
and the creation form for the object Y contains a reference to the<P>
object X. Initialization forms are not subject to any restriction<P>
against circular dependencies, which is the reason that initialization<P>
forms exist. See the example of circular data structures below.<P>
<P>
-5- The creation form for an object is always evaluated before the<P>
-5- initialization form for that object. When either the creation form or<P>
-5- the initialization form references other objects of user-defined types<P>
-5- that have not been referenced earlier in the <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, the<P>
-5- compiler collects all of the creation and initialization forms. Each<P>
-5- initialization form is evaluated as soon as possible after its<P>
-5- creation form, as determined by data flow. If the initialization form<P>
-5- for an object does not reference any other objects of user-defined<P>
-5- types that have not been referenced earlier in the <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, the<P>
-5- initialization form is evaluated immediately after the creation form.<P>
-5- If a creation or initialization form F references other objects of<P>
-5- user-defined types that have not been referenced earlier in the<P>
-5- <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, the creation forms for those other objects are evaluated<P>
-5- before F, and the initialization forms for those other objects are<P>
-5- also evaluated before F whenever they do not depend on the object<P>
-5- created or initialized by F. Where the above rules do not uniquely<P>
-5- determine an order of evaluation, which of the possible orders of<P>
-5- evaluation is chosen is unspecified.<P>
+5+ The creation form for an object is always evaluated before the<P>
+5+ initialization form for that object. When either the creation form or<P>
+5+ the initialization form references other objects that have not been<P>
+5+ referenced earlier in the file being compiled, the compiler ensures<P>
+5+ that all of the referenced objects have been created before evaluating<P>
+5+ the referencing form. When the referenced object is of a type which<P>
+5+ <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> processes using <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>, this involves evaluating<P>
+5+ the creation form returned for it. (This is the reason for the<P>
+5+ prohibition against circular references among creation forms).<P>
+5+<P>
+5+ Each initialization form is evaluated as soon as possible after its<P>
+5+ associated creation form, as determined by data flow. If the<P>
+5+ initialization form for an object does not reference any other objects<P>
+5+ not referenced earlier in the file and processed by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> using<P>
+5+ <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>, the initialization form is evaluated immediately after<P>
+5+ the creation form. If a creation or initialization form F does contain<P>
+5+ references to such objects, the creation forms for those other objects<P>
+5+ are evaluated before F, and the initialization forms for those other<P>
+5+ objects are also evaluated before F whenever they do not depend on the<P>
+5+ object created or initialized by F. Where these rules do not uniquely<P>
+5+ determine an order of evaluation between two creation/initialization<P>
+5+ forms, the order of evaluation is unspecified.<P>
<P>
While these creation and initialization forms are being evaluated, the<P>
objects are possibly in an uninitialized state, analogous to the state<P>
of an object between the time it has been created by <A REL=DEFINITION HREF="../Body/f_alloca.htm#allocate-instance"><B>ALLOCATE-INSTANCE</B></A><P>
and it has been processed fully by <A REL=DEFINITION HREF="../Body/f_init_i.htm#initialize-instance"><B>INITIALIZE-INSTANCE</B></A>. Programmers<P>
writing methods for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> must take care in manipulating<P>
objects not to depend on components that have not yet been initialized.<P>
<P>
It is implementation dependent whether <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> calls <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> on the forms or<P>
does some other operation that has an equivalent effect. For example,<P>
the forms might be translated into different but equivalent forms and<P>
then evaluated, they might be compiled and the resulting functions<P>
called by <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>, or they might be interpreted by a special-purpose<P>
interpreter different from <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>. All that is required is that the<P>
effect be equivalent to evaluating the forms.<P>
<P>
Examples:<P>
{use existing examples}<P>
<P>
Affected By:<P>
None.<P>
<P>
Exceptional Situations:<P>
Certain methods signal an error when called, indicating that<P>
\arg{object} cannot be used as a constant in code being processed by<P>
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
<P>
See Also:<P>
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A>, ``Compilation'',<P>
``Evaluation''.<P>
<P>
Notes:<P>
Some implementations may <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> facilities for defining new subclasses<P>
of classes which are specified as \term{system classes} by this<P>
<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> (some likely candidates include <A REL=DEFINITION HREF="../Body/t_generi.htm#generic-function"><B>GENERIC-FUNCTION</B></A>, <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>METHOD</B></A>, and<P>
<A REL=DEFINITION HREF="../Body/t_stream.htm#stream"><B>STREAM</B></A>). Such implementations should document how <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> treats<P>
instances of such classes when encountered as constants, and should<P>
document any relevant methods for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>.<P>
<P>
2. Change the syntax of <A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> to<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> object &amp;key :slot-names :environment<P>
<P>
\arg{Environment} is an environment object, and is the environment in which<P>
the forms will be processed.<P>
<P>
<B>Proposal (MAKE-LOAD-FORM-CONFUSION:REWRITE-WITH-POSITIONALS):<P>
</B><P>
Same as <A HREF="iss236.htm">MAKE-LOAD-FORM-CONFUSION:REWRITE</A>, except that the syntax for<P>
<A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> is changed to<P>
<P>
<A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> object &amp;optional slot-names environment<P>
<P>
<B>Editorial Impact:<P>
</B><P>
A new version of <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> must be integrated into the document. It is<P>
intended that this be a matter of making stylistic edits, formatting, and<P>
getting fonts right for defined names, glossary terms, and such.<P>
<P>
Small changes to <A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A>.<P>
<P>
Possibly some small changes to the description of constant processing by<P>
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
<P>
<B>Rationale:<P>
</B><P>
Adding optional environment arguments to these functions provides them with<P>
access to the environment in which the forms to be returned will be processed<P>
by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
<P>
The rewrite attempts to fix the problem that the original specification of<P>
<A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> said something much stronger than was perhaps actually<P>
intended, while still providing programmers with some guarantees about the<P>
behavior of <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> when applied to instances of portable classes.<P>
<P>
The intent is that programmers may define portable classes with the knowledge<P>
that these classes will not be unintentionally inheriting supposedly useful<P>
but actually inadequate methods for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> provided by the<P>
implementation, while still permitting <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> to use <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> for<P>
handling instances of classes which are specified as possibly being built in<P>
classes and for instances of additional implementation specific classes.<P>
<P>
Adding a <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> signature for <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>CLASS</B></A> fills the gap mentioned in the problem<P>
description. Some portions of the mechanism for performing the name to <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A><P>
lookup are implementation defined in order to permit extensions (such as<P>
forward referenced classes). This <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> is needed because <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> metaobjects<P>
are valid type specifiers and so may be expected to appear directly in code to<P>
be compiled.<P>
<P>
<B>Current Practice:<P>
</B><P>
Lucid plans (in a future release which includes <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A>) to <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> the<P>
<A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> signature <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> (object <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>CLASS</B></A>), which will return a form that<P>
looks up the <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> by name, returning a forward referenced <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> if necessary.<P>
<P>
Symbolics removed the <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> (object <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>CLASS</B></A>) from their current<P>
development system, both because of technical issues related to extensions and<P>
because of a belief that there were unresolved semantic issues. This proposal<P>
attempts to deal with those issues.<P>
<P>
Presumably nobody has yet given <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> an optional second argument.<P>
<P>
<B>Cost to Users and Implementors:<P>
</B><P>
All existing methods for <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> will have to be modified to accept the<P>
optional second argument. Some methods might need to be modified to use the<P>
argument, rather than simply ignoring it. Probably the number of methods<P>
involved is small, and both implementors and users will presumably be alerted<P>
to unmodified definitions because of lambda-list congruency failures.<P>
<P>
Calls to <A REL=DEFINITION HREF="../Body/f_mk_l_1.htm#make-load-form-saving-slots"><B>MAKE-LOAD-FORM-SAVING-SLOTS</B></A> will need to be examined to determine<P>
whether there is a missing environment argument that needs to be supplied, and<P>
figure out where that environment is supposed to come from. Since most calls<P>
to this function are likely to be in <A REL=DEFINITION HREF="../Body/f_mk_ld_.htm#make-load-form"><B>MAKE-LOAD-FORM</B></A> methods, this is probably<P>
going to be easy in virtually every case.<P>
<P>
<B>Discussion:<P>
</B><P>
There was significant divergence of opinion regarding the treatment of <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A><P>
metaobjects as compiled constants. Some discussion revolved around the issue<P>
of whether the name to <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> mapping was sufficiently dependable to make<P>
dumping by loadtime name lookup a reasonable choice, and whether this facility<P>
was needed at all. The principal point of debate was the question of what to<P>
do at loadtime when <A REL=DEFINITION HREF="../Body/f_find_c.htm#find-class"><B>FIND-CLASS</B></A> doesn't find a <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A>. The passage from<P>
COMPILE-ENVIRONMENT-CONSISTANCY regarding classes defined with <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A> bears<P>
on both of these questions. The current description is a compromise whose<P>
intent is to permit but not <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> certain kinds of extensions, while<P>
providing users with confidence that something well defined will happen if<P>
this situation (which COMPILE-ENVIRONMENT-CONSISTANCY can be interpreted as<P>
saying is an error) occurs.<P>
<P>
Moon, regarding environment information<P>
As I keep saying over and over (although I guess I must not have been<P>
listening to myself when I first proposed make-load-form!), no form has any<P>
meaning without an accompanying environment.<P>
<P>
JonL, in response to the question<P>
Will users complain if we don't add the ability to fasdump named <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A><P>
objects to the language? <P>
<P>
Already have. In droves. Probably because class-objects are written into<P>
the language as first-class type-specifiers, and are being incorporated into<P>
programs (as constants) with impunity.<P>
<P>
Moon and Barrett both prefer proposal REWRITE over REWRITE-WITH-POSITIONALS.<P>
</PRE>
<HR>
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
</BODY>
</HTML>
View git blame Copy permalink