[plt-scheme] (typeof obj)
Yes, at the C level, MzScheme knows the type tag. But, on the Scheme
level, everything is suppose to be transparent.
As discussed in a previous thread on this maillist :
http://list.cs.brown.edu/pipermail/plt-scheme/2007-May/017815.html, one
can easily create a new "primitve type" in Scheme. The new type is just
Scheme struct at C level, but you can't tell that in Scheme level: even
(struct? a-data-with-this-new-type) returns #f. So the new type is
totally INDISTINGUISHABLE from other build-in types! How good a
"type-of" procedure as you are suggesting work with this idea?
This is my understand to this question. Hope this answers the
"historical design decisions" question.
Chongkai
Jos Koot wrote:
> I wonder too, for all that is needed seems to be in the C code.
> Chapter 2 of 'Inside PLT MzScheme' gives info on how type info is
> recorded 'inside' MzScheme. The following is what I collected from
> looking into the doc and the C code: C macro SCHEME_TYPE returns
> type-info. File .../src/mzscheme/src/stypes.c enumerates scheme types
> used inside MzScheme. I guess it would not be very difficult to add C
> code that collects the scheme-type and uses it to collect a type-name
> from an array of strings. May be elsewhere such an array already
> exists, I would not know. Adding a primitive that returns the
> string may do what you are looking for. Jos Koot
>
> ----- Original Message -----
> *From:* YC <mailto:yinso.chen at gmail.com>
> *To:* Jos Koot <mailto:jos.koot at telefonica.net>
> *Cc:* PLT Scheme List <mailto:plt-scheme at list.cs.brown.edu> ;
> Robert Nikander <mailto:nikander at nc.rr.com>
> *Sent:* Monday, June 11, 2007 7:49 AM
> *Subject:* Re: [plt-scheme] (typeof obj)
>
> Agreed that it would be implementation dependent, but if the type
> info has to be calculated every time on the fly it can be both
> inefficient and incorrect (if all values are just bytes, it could
> satisfy more than one disjointed types that lead to incorrect
> semantics), hence I venture that Scheme value has type attached -
> but sure would love to be enlightened on this point.
>
> Regarding whether a list of number is a list or a list of numbers
> - I can see that comes up with either predicates or type info, so
> don't see a disadvantage one way or another, but predicate-based
> approach just makes type dispatching more manual.
>
> Anyhow - just wondering about the reason(s) not to provide type
> info - sure love to know the historical design decisions ;)
>
> Thanks,
> yinso
>
>