[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opaque type proposal
This looks fine modulo a couple of questions:
1 -- Why does the ``type-id'' argument have to be a symbol? I could well
imagine wanting a name like "Compiled Function", which is a pain to have to
translate into a symbol first.
2 -- The point came up here that it would be useful to have a procedure that,
given any Scheme value, returns an object in some way representing the ``type''
of that object. If two values have the same ``type'', then this hypothetical
procedure would return EQL objects on the two values. This sort of thing would
be useful for packages that want to allow ``registration'' by clients of
type-specific operations. The registration mechanism would associate an
operation with a ``type-object'' in some table. When it came time to apply the
generic operation to a value, the type-object for the value would be mapped to
the type-specific operation, which could then be applied.
Of course, for some of the built-in types there are problems with this. For
example, do 3 and #i3 return the same ``type-object''? I think that there are
reasonable choices that can be made for such questions.
In essence, we'd be interested in a facility like the TYPEP and TYPE-OF
functions of Common Lisp but without the issue of type names.
Of course, an obvious choice for the ``type-object'' would be the ``record
type'' objects in your proposal, but, as you say, mapping from objects to their
``record type'' objects is an abstraction-breaker.
Pavel