On Sat, 2005-02-12 at 16:26 +0100, J�rgen Hermanrud Fjeld wrote:
> > Interfaces may extend other interfaces:
> >
> > (definterface suptype
> > (extends supertype)
> > ... new methods ...)
> >
> Such that extends is reuse of function signatures?
and the names to which they are bound.
> > The major open question on DEFINTERFACE is whether we should provide an
> > extra level of indirection to reduce space consumption. That is, should
> > an interface instance be a structure whose members are closed over
> > state, or should it be a pair of pointers (state, real-method-structure)
> > [i.e. vtable like] with compiler support? I would be very interested in
> > opinions on this question.
> >
> But if state is produced by invoking some function in the interface,
> then the other functions that do something useful would take explicit
> parameters, and you would have modules as found in ML-like languages.
> If I imagine ML-like modules with existential and hidden types, which
> represent the state, is that understanding somewhat on the right track?
> If yes, this hints at a type system similar to GADTS by Peyton Jones.
I don't know enough about ML modules to answer this. What I had in mind
in this scenario was that an interface would, in effect, have a hidden
parameter (the state), and the
method(args)
would transparently be rewritten by the compiler as
methodImpl(state, args);
> > Note that there has been a revision to the specification of typecase:
> > the right hand sides are not required to evaluate to expressions of the
> > same type.
> >
> So extensible-plus is universally quantified over 'a and 'b, and there
> exists a run-time representation of types such that at run-time the
> typecase can be evaluated, and there is no compile time checking that
> uses of extensible plus are type correct, but a run-time exception will
> always be thrown if extensible-plus is used incorrectly?
Absolutely not! If typecase fails to match the type, it is **compile
time** type error. There is no runtime representation of types here. If
I have missed something in such a way that there *needs* to be a runtime
representation of types, this mechanism needs to be removed.
> Or is extensible-plus quantified over a restricted set of types, to
> facilitate compile time checking, and there is a run-time evaluation of
> typecase?
The intent is that the type matching of typecase should be done entirely
at compile time. The end effect is intended to be predicated types.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
