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

TYPE-OF

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)
3
; FIXNUM
D-Eval>(cdr '(a))
()
; NULL
D-Eval>(ndefmeth foo ((x integer)) (+ x 1))
FOO
; SYMBOL
D-Eval>(foo 1)
2
; FIXNUM
...


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
>as RANDOM.
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.
Thank you.

>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.
>
>  Rob
>
----------

>Date: Tue, 18 Nov 86 16:04 EST
>From: Robert W. Kerns <RWK%YUKON.SCRC.Symbolics.COM@u-tokyo.junet>
>In-Reply-To: <8611170906.AA16158@ccut.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.
And,
the value (type) should be at the bottom of hierarchy chart whenever it is possible.
For example,
(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)
>
>    T>{pathname,stream,hash-table,readtable,package,random-state,
>
>	 '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").

Masayuki Ida