Jonathan S. Shapiro wrote: > And no, off-hand I don't have any particular use for compile-time > constant quantification in general, but there does turn out to be one > very important case: procedure objects for statically resolvable > procedures. > > In particular, we can take the view that in: > > (deftypeclass (myTC 'a) > proc1: (fn 'a bool) > proc2: ...) > > (define (f x) > (proc1 x)) : > (forall (myTC 'a) (fn 'a bool)) > > the type of procedure /f/ should be read to mean: > > (forall ((myTC 'a) proc1:(myTC 'a).proc1) (fn 'a bool)) > > which is to say: > > "we require a type 'a that satisfies (myTC 'a), and we further > require a compile-time resolvable binding of proc1 satisfying the > type 'methods of (myTC 'a) named proc1'" > > If we adopt this view, then what happens is that the method binding > occurs at the outermost point where (myTC 'a) is instantiated by the > polyinstantiator, and that resolution percolates inwards across any > calls into libraries and so forth. The *binding* rule can now be lexical > and unambiguous without sacrificing any ability to build generalized > libraries.
I did not understand this case completely. I think you are tring to achieve some form of compile time resolvable dictionaries, right? First, you said that the polyinstantiator propagates these bindings into other definitions. Here, if all propagation needs to happen at compile time (that is, the 'literal' proc1 is not passed as argument into library routines), doesn't it require whole program compilation? Second this kind of quantification over procedure names reveals more information about the implementation of a function (ex: the type of f reveals the fact that it calls proc1). So, I guess these quantifications must be always be explicitly declared. Swaroop. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
