[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
answers to your questions
I decided I better CC these answers to quinqevirate as an extra check
on my accuracy.
Date: 5 May 89 15:52
From: chapman%aitg.DEC@decwrl.dec.com
Following are some further questions on 2.2, the 4.1 source file
has more questions (preceded by "***").
>Subj: comments on comments on section 2.2
> >p.2-32ff: the many type specifiers added by CLOS are missing, including
> >EQL, the new built-in types like STANDARD-OBJECT and GENERIC-FUNCTION,
> >and the ability to use a class object as a type-specifier.
> I will need some help figuring out how the CLOS types fit here. I had
> planned to generate a clean-up about this and the Condition System
> types after Gregor(?) and KMP help me construct this correctly. Maybe
> it's straightforward, but when I started to do it on my own I ran into
> too many questions.
>
>It shouldn't be necessary to make any decisions, but you may need some
>help decoding the existing documents. I'll be happy to answer any questions
>you have. I don't think a Cleanup should be necessary, as the types have
>already been put into the language by acceptance of earlier documents.
>All we have to do is gather the existing information into a single place
>and put it into a uniform format. I believe none of the CLOS and Condition
>type specifiers take arguments, which makes things simpler.
1. Where can I find the type hierarchy for standard-object, standard-class,
built-in-class, and standard-object?
Here's some material from a draft of chapter 3. This much I believe.
STRUCTURE-OBJECT, STANDARD-OBJECT, GENERIC-FUNCTION, METHOD,
METHOD-COMBINATION, and CLASS are disjoint and each has superclass T.
STANDARD-CLASS, STRUCTURE-CLASS, BUILT-IN-CLASS,
STANDARD-GENERIC-FUNCTION, and STANDARD-METHOD are disjoint and have
superclass CLASS, CLASS, CLASS, GENERIC-FUNCTION, and METHOD
respectively. No exhaustive partitions here. Those are all the classes
I could find in 88-002R; chapter 3 adds some more but we can forget
about them for now.
I don't know why STRUCTURE-OBJECT isn't named STRUCTURE (the name
Symbolics Genera uses). The symbol STRUCTURE already exists in
CLtL Common Lisp (as a word used by the DOCUMENTATION function),
so it seems like the appropriate word.
2. Which classes are actually defined be the CLOS chapters we accepted and
which ones are part of Chapter 3? Are we including some info from Chapter 3
to make the parts we accepted make more sense?
See above.
This doesn't settle all the chapter 2 versus chapter 3 questions, e.g. what
good is ADD-METHOD without chapter 3. I don't want to think about those now.
3. What is the supertype of types RESTART and CONDITION (t, I assume)?
In most implementations, it will probably really be STANDARD-OBJECT, but I
guess the spec should only say T; similar to PATHNAME, RESTART and CONDITION
should be implementable as builtin, structure, or standard class at the
implementor's discretion.
What is the
relationship of the condition system data types to each other (disjoint,
exhaustive partition, ...)?
CONDITION and RESTART, like PATHNAME, are disjoint with everything else,
and with each other. The subtypes of CONDITION have defined relationships
in the condition system document, if I remember correctly.
>p.2-5 second bullet from the bottom: This extends a CLtL comment about
>DEFSTRUCT to DEFCLASS. However, it does not work for DEFCLASS because
>of multiple superclasses. Two classes A and B can have a common subclass
>C, even though A is not a superclass of B and B is not a superclass of A.
>In this case A and B are not disjoint. What you want to say instead is
>that the type relations explicitly created by specifying superclasses
>are the only type relations, or words to that effect.
How about these words:
"Any two {\word classes\/} created by {\function defclass\/}
are related only by
the type relations explicitly created by the {\word superclasses\/} specified
during class creation."
>Okay except I would change "by the type relations explicitly created by"
>to "according to". But maybe this would be better: "Any two {\word
>classes\/} created by {\function defclass\/} are {\word disjoint}
>unless they have a common {\word superclass}." [That assumes that
>our definition of superclass says every class is a superclass of
>itself, which I think is the case, but did not check.]
CLOS (and now section 2.3) says "A class is considered neither a
superclass nor a subclass of itself." So I used "according to".
You lost the context of this remark. I've restored it above, since I
fortunately hadn't gotten around to deleting the mail yet. The wording
you chose is not wrong, but I still think it's a pity we don't have a
term that includes a class as well as its superclasses, so that we can
use the much more explicit wording I suggested. The Flavors word for
this is "component". Even without such a term, I think we could say:
"Any two {\word classes\/} created by {\function defclass\/} are {\word
disjoint} unless they have a common {\word superclass} or one {\word
class} is a {\word superclass} of the other."
Also I think it may be perceived as odd that a type is a subtype and
a supertype of itself (CLtL p.72), but a class is not a subclass nor
a superclass of itself. We can't really change the nomenclature for
types, since it derives directly from the mathematics of sets. I'm
not sure what would be the impact of changing the nomenclature for
classes so that what is now "subclass" would become "proper subclass",
and what is now "superclass" would become "proper superclass". This
would (clearly) not affect "direct subclass" and "direct superclass".
>Now somewhere in 6.1: The reference to APL is questionable, does this mean
>we are incorporating some specific standard by reference (then we should
>give its exact name), or is it just a general remark?
I cited the whole reference this time.
It still doesn't tell me how to order a copy, or is that in a bibliography
elsewhere?
I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
just refer to another standard instead of giving the branch cut rules explicitly.
There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
Maybe the branch cut rules are given explicitly, but I haven't been able to find
them. After mentioning the APL document, section 6.1 goes off to talk about
something unrelated.
Section 4.1:
[If an operator symbol doesn't name a function, special form, or macro]
An error of type {\datatype undefined-function\/} might be signalled.
*** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
has been withdrawn. So I guess we can't adopt its contents, but what
about ``might'' in place of ``should''?
My notes say it's deferred to the June meeting to fix the CLOS slot
part, not withdrawn. That's independent of the function part, and I
think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
proposes). Can we just change it to "should" or do we have to go
through the cleanup committee?
\itemitem{{\bf Apply:\/} returns the result of the evaluation of the last form
in the lambda body}
*** Moon's comment is that {\function apply\/} is also referenced for
named functions. What to do here?***
Following is the algorithm for {\bf apply\/}.
\beginlist
\itemitem{1.} Find all declarations.
\itemitem{2.} Create new dynamic and lexical contexts.
*** David, please suggest a fix for this.***
\itemitem{3.}{\bf Evaluate forms\/} in the lambda body in the lexical and
dynamic contexts.
Well, I think APPLY is a way of getting some arguments to a function,
and shouldn't say anything about what happens inside the function.
Thus parameter matching, declarations, environments ("contexts"), and
forms in the body shouldn't be mentioned in connection with APPLY.
Maybe APPLY is just completely the wrong word here, and APPLY-LAMBDA
is the word JAR should have used.
The stuff listed here under APPLY correctly belongs under a description
of "calling a lambda", something that both APPLY and FUNCALL do.
Except, we don't call lambdas, we call functions, and lambdas aren't
functions. I couldn't find anything in section 4.1 that was clear about
this, although I was hampered by only looking at TeX source. Thus I
couldn't find the right name for this. What you are trying to describe is
the semantics of calling a user defined function, regardless of whether
that function is defined with DEFUN, FLET, or LAMBDA, and independent of
whether the semantics are implemented by an interpreter or a compiler
(thus independent of whether all the actions are happening at the time
the function is called, or some happened ahead of time). That's all the
help I can offer right now, I sure hope it's enough.
BTW section 4.1 still appears to suffer from saying everything twice,
although it's hard to be sure when reading TeX source. I guess that's
the import of
*** David, please suggest where you want this information to go***
What I want is not for the text attached to that to be moved someplace
else, but to merge or eliminate the duplicated descriptions. For
example, \beginsubsubsection{Symbols as Forms} is about the same topic
as \itemitem{{\bf Variable evaluation:}, and each of them says something
about that topic that the other one fails to say. The two pieces of
text need to be combined and cast into a consistent style, without losing
any of the contained information. Similarly for evaluation of the other
kinds of forms. I don't think I can do this rewriting myself.