Hello again. On Sat, Feb 12, 2005 at 08:36:38AM -0500, Jonathan S. Shapiro wrote: > [...] > In short, most of the current uses of subclassing are either (a) bad > idioms, or (b) good idioms overlayed on the wrong mechanism. BitC takes > the position that most languages have erred by confusing interface types > with object implementations. What we want is the ability to define > something like Java interfaces, whose type is a set of ( method-name, > signature ) pairs. > I assume you mean something like ML modules, because signatures are independent of the module, modules just group them, like you describe, while java interfaces has signatures that are relative to the interface
> ** BitC Interfaces
>
> BitC will have a form DEFINTERFACE:
>
> (definterface stream
> get : (fn () char)
> put : (fn (char) ())
> ... )
>
> At present, an interface will consist exclusively of functions. We *may*
> augment this in the future to include arbitrary deep-frozen constants.
>
> Interfaces may extend other interfaces:
>
> (definterface suptype
> (extends supertype)
> ... new methods ...)
>
Such that extends is reuse of function signatures?
> [...]
> 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.
> [...]
> (define (extensible-plus x:'a y:'b)
> (typecase (tuple a b)
> ... dispatch on legal argument type pairs ...))
>
> 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?
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?
And are there compile time optimizations of typecase?
If the quantification of extensible-plus is expressed in the type
system, then type classes [1] could express that, and to optimize the
run-time representation of types and the compilation of typecase,
when the constraints are present at compile time, the concept of
flows [2 Sec.9] from extensional polymorphism could be useful.
[1] Mark P. Jones, 1995
Functional Programming with Overloading and Higher-Order Polymorphism
http://citeseer.ist.psu.edu/jones95functional.html
[2] Jun Furuse, 2002
Extensional Polymorphism: Theory and Application
http://pauillac.inria.fr/~furuse/thesis/thesis_furuse.ps.gz
--
Sincerely | Homepage:
J�rgen | http://www.hex.no/jhf
| Public GPG key:
| http://www.hex.no/jhf/key.txt
signature.asc
Description: Digital signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
