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? If a module has an existential type t, then the structure of t is only visible inside the module, and that is a record/tuple/whatever that contains the state, the user of the module can not inspect the state, but is required to store it and pass it at the right places, according to the signature. To prevent every module from inventing a different name for the state, the compiler could require every module to have an existential type named state, or some other compiler enforced convention, which can be translated into a module with an existential type. By the way, O'Caml uses the term abstract type for module hidden types. > [...] > 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. > Well, with your previous example this sounds like type classes to me, and they do have run-time representation of types, but your point is about necessity. 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. Extensional polymorphism assumes a closed world, but open recursion, which complicated the picture. The closed world assumption is that the instances of a generic function is defined before it is applied, hence one can decide if the generic function can be applied. The open recursion assumption states that at a later point, the generic function can be extended, which changes the array of functions that is created for the generic function. With your limited form for polymorphism, you could maybe avoid the open recursion, or only allow appends to the array of functions, hence the address of the correct function alternative can be fetched, and the jump can be made directly, without run-time types. A generic function would be stored as an array of function offsets at compilable unit boundary, and looked up at compile time. I would expect such an approach to work, hence also other similar approaches, such as union types of some kind, although I have no good references for type systems with union types. Just for the sake of asking, do you consider polymorphic functions unusable for BitC if they are at all slower than regular function calls? I assume so, and then agree with the current polymorphic approach for BitC. Given a surprising no, extensional polymorphism mixed with staging annotations could be a very interesting research exercise, given one could live with the extensional polymorphism overhead until the topic was researched. > [...] > 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? -- 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
