[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
This mail is the reply to RAM's mail and RWK's mail.
(And I just read Fahlman's mail and Masinter' mail on posting this.
this mail is not directly related to my committee work for the standardization)
My trigger to think of TYPE-OF (and SUBTYPEP) is the definition of
the Common Lisp interpreter including CommonLoops.
I've been thinking of it since last November before PCL was there.
(And presented a paper on Dec. 1985 in Japan)
I named it Discriminating Eval (D-Eval).
D-Eval is an executable model of Common Lisp scheme.
D-Eval always keeps track of the type of a object.
With this D-Eval, Common Lisp can, I think, bridge the object oriented world and
lisp, and formal systems.
I feel several researchers are independently working in near here.
(If someone is interested in D-Eval I will send a version of it to anyone)
Here is a conversation with D-Eval:
D-Eval>(+ 1 2)
D-Eval>(ndefmeth foo ((x integer)) (+ x 1))
Then, I will try to discuss.
>Date: Mon, 17 Nov 1986 18:03 EST
>From: Rob MacLachlan <RAM%C.CS.CMU.EDU@u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 12:58:34-JST (Wed)
>It would also be wrong for NIL to be returned to indicate a random
>object, since NIL is a meaningful type, but not one that any object
>can posess. It would make more sense to return T or a new type such
I understood. I confess that I did not make a deep consideration on random object prior to posting my mail.
I am wrong.
They should not goto NIL.
>I also have some doubts about the need to specify what Type-Of
>returns. Could you demonstrate some code that needs to use Type-Of
>and is adversely affected by different implementations? I suppose
>that we could rigorously specify some function that does what you
>want, but it shouldn't be Type-Of.
D-Eval concept needs TYPE-OF.
kinds of type inferencing system will also need TYPE-OF to determine the type.
>Date: Tue, 18 Nov 86 16:04 EST
>From: Robert W. Kerns <RWK%YUKON.SCRC.Symbolics.COM@u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 15:19:54-JST (Wed)
> ... Your question really relates to one of the core
>issues of this topic.
I think so if my image of SUBTYPEP is same as yours.
> ... And SUBTYPEP/TYPEP
>is what answers the question "is this object suitable."
>Given this model, there is no such thing as "too specific"
>an answer from TYPE-OF. On the contrary, the concern should
>be with "not specific enough".
>To address your specific points:
> Date: Mon, 17 Nov 86 18:06:12+0900
> From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT,
>RATIO, or one of their subtypes (if any), or some other subtype of NUMBER.
TYPE-OF of a number must return one of the FIXNUM, BIGNUM, RATIO, SHORT-FLOAT,
SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT, COMPLEX. If TYPE-OF can not return
one of the above, it must return the type which is closer to the above terminal type.
>However, it does not make sense to specify that TYPE-OF return one
>of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented
>all numbers as "BIGNA" would be correct, if inefficient.
>And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and
>POSITIVE-BIGNUM. If you specify that TYPE-OF return just BIGNUM,
>you prevent any program from distinguishing between them, when it
>may be the program's advantage to make the distinction.
NEGATIVE-BIGNUM and POSITIVE-BIGNUM are not defined in Common Lisp,
though they are possible to exist.
>By over-specifying TYPE-OF, you can eliminate any implementation
>flexibility or extensibility.
TYPE-OF story and implementation flexibility are quite different.
I think the definition of TYPE-OF is needed to keep Common Lisp as well-defined.
It is the issue of formality.
What I said is TYPE-OF should return the name of the symbol which is defined in the language specification.
the value (type) should be at the bottom of hierarchy chart whenever it is possible.
(type-of ()) should not be SYMBOL as in some CL implementations, but NULL.
>TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return
this symbol is not in my dictionary.
Again, I think TYPE-OF should not return implementation dependent things.
>the values T T when asked if this is a subtype of BIGNUM, of INTEGER,
>and of NUMBER.
>SUBTYPEP is the only predicate provided for comparing types;
>it goes without saying that any code that uses something else
>like EQUAL will not be portable. Any type you get back from
>TYPE-OF you must interpret with SUBTYPEP.
> I had wrote a hierarchy chart based on 2.15.
> which is attached on the japanese edition of CLtL.
> Here is a brief sketch of it.
>The english version of CLtL would be clearer if it
>included something like this.
I think so. ( I already sent it to GLS)
> 'nil' is for undefined object, say unreadable objects.
>No, not NIL. T would be a better choice here than NIL!
Thank you. As I answered to RAM's message, I am wrong.
> .... There is nothing wrong with having
>an UNDEFINED type, however. ...
Will you push to make UNDEFINED type ?
I think its interesting.
I want to add one more thing.
(type-of "string") must return SIMPLE-STRING. SIMPLE-STRING is a subtype of
STRING and SIMPLE-ARRAY simultaneously.
If this call returns STRING, SIMPLE-ARRAY related things can not handle
the things caused by (type-of "string").
- From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>