[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