On Mon, 2005-02-14 at 21:40 +0100, J�rgen Hermanrud Fjeld wrote:
> On Sat, Feb 12, 2005 at 10:36:35AM -0500, Jonathan S. Shapiro wrote:
> > On Sat, 2005-02-12 at 16:26 +0100, J�rgen Hermanrud Fjeld wrote:
> > [...]
> > > Such that extends is reuse of function signatures?
> > and the names to which they are bound.
> >
> Yes.
>
> > [...]
> > 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);
> >
> Could you provide a notion as to why this scheme is better than a
> module with an existential type that contains the state?
> Since you have abandoned the object-oriented approach, why not just use
> modules, and the corresponding theory which is well known?
Which modules? The SML module system is horribly complicated and not
well motivated. Dave made a decision -- in my opinion a poor decision --
to conflate objects and modules.
However, it may be that what we are proposing is equivalent w.r.t. the
presence of existential type or abstract types. If so, I'm not eager to
reinvent the type system ideas. I *do* want to make a clean separation
between objects and modules.
> Bear with me here, but imagine extensional polymorphism, where a
> generic function is a specification of overloading. Then a generic
> function is compiled to an array of functions, where each type case
> corresponds to an index in that array. By flow optimization a generic
> function application is translated into an array lookup, at a compile
> time known offset, and then a dispatch to the function at the offset....
J�rgen:
I run into two problems in this discussion. The first is that I don't
understand what existential types are -- please try to remember that my
group is *not* a PL group. What you are witnessing is a group of people
that (collectively) has very deep experience with language design but
almost no experience at all with type systems. We often find that we
discover an implementation that is workable and reason backwards to
discover that there is a corresponding type system. We are learning as
we go, and you have been a great help, but try to use small words :-).
For myself, I have been in proposal writing mode, and I haven't caught
up on some of your suggested reading. Also, the term "existential types"
is not universally understood to have a common meaning. In order for us
to have a common conversation, can you provide a link to some paper that
describes what you mean by existential types?
My second problem is that we desperately need to keep fancy compilation
techniques OUT of the requirements for compiling the BitC language. If I
have to make a choice between "transparency" and "flexibility of type
system", I'm going to choose transparency. One of the goals is that we
should be able to build a compiler to C with minimal optimizations
required. Because I do not understand the implications of existential
polymorphism, I am unable to determine whether there is an interaction
with this goal. I would appreciate your help in understanding this.
> Just for the sake of asking, do you consider polymorphic functions
> unusable for BitC if they are at all slower than regular function calls?
Yes.
> > [...]
> > 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.
> >
> Could you provide a reference to work on predicated types?
Embarrassingly, the answer is no. Perhaps Swaroop will be able to do so.
The idea I am trying to describe is that given a polymorphic function
f : 'a x 'b -> 'c
it is necessary that for any given choice of 'a and 'b there should be
exactly one result type 'c, but the result type may be different for
different input types. A consequence of this is that we may view the
result type as "predicated" on the input types.
This may be perfectly obvious, and it may already be implicit in the
notion of polymorphic functions. If so, then I should not be introducing
a new term for it and I would appreciate a correction.
Jonathan
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
