On Thu, 2008-07-17 at 13:19 -0400, Swaroop Sridhar wrote: > Jonathan S. Shapiro wrote: > > 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?
That is certainly what I am trying to do here. More generally, I am mentally exploring a generalized form of quasiterm substitution that looks like it happens to be able to solve this problem. > 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? Yes. But step back a moment. C requires whole-program compilation too. When you get a .o, you haven't got a program yet. The difference between today's C output and today's BitC processing model is that the nature of the actions that must be taken to connect multiple .o's into an executable are qualitatively much simpler than the nature of the actions required to produce the .o's in the first place. Specifically: connecting multiple .o's requires symbol resolution, common area symbol unification, and linker section concatenation. In later linkers we also need to deal with weak symbols, but that isn't a huge conceptual leap. I am trying to get BitC to the point where it has a comparably low-level set of requirements to connect object files. Those appear to be: symbol resolution instantiation by type (which can be encoded as symbol resolution) instantiation by literals (including sizes of types) You and I have talked about this much. This new notion that I am playing with of instantiation by quasiterms is merely a generalization of instantiation by literals. > 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. Yes and no. If /f/ is a procedure that involves a constrained type (myTC 'a), then we already know that /f/ makes some call on some (unspecified) method of myTC. It is not necessary to know *which* method. What is necessary is to know that any method defined by myTC *might* be invoked by /f/, and we therefore need to provide a method dictionary for all of those methods. The method dictionary is a compile-time constant, and we can now use partial evaluation at link time (implemented via the substitutions listed above) to make the dictionary references disappear if we wish to do so. So w.r.t. typeclass methods I am saying that there is no new disclosure, because we do not require the degree of specificity that you assumed. However, w.r.t. literals (or more generally: quasi-terms), yes, they must be declared at the original point of use and the unifier must propagate those constraints in the same way that it propagates type class constraints. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
