On Thu, 2005-08-11 at 15:32 -0400, M. Scott Doerrie wrote: > How do type classes propagate over interfaces? Are definstances > declared locally in imported interfaces available without declaration in > the interface definition?
There are two issues here. 1. Type classes do not propagate, but instantiations are contagious across import boundaries. They have to be. 2. It is possible to construct situations where a procedure receives arguments such that it does not know the particular instantiation but it did receive a hidden argument providing the method dictionary pointer. In this case you know enough to invoke even though the instantiation is not in scope. Unfortunately, you *don't* know enough to know whether the instantiation satisfied the deeply immutable constraint (because the instantiation is not in scope). This is why it needs to be declared as a property of the typeclass. > >3. Introduce a new variation on function types: > > > > (di-fn T.arg T.result) > > > >that describes deeply immutable procedures. > > > > > If I declare a di-fn using a type class, other future instances of that > type class could cause my function to become stateful. A DI-FN can only be instantiated by a deeply immutable procedure. Otherwise you get a compile time error. All methods of a deeply immutable typeclass are DI-FNs. The problem is that when you go to instantiation the DI-FN using (definstance (TC mumble) some-fn) you need enough visible type information to know that some-fin is in fact a DI-FN, and the current type system does not capture that information. If we have deep immutability at all, we need a way to declare deeply immutable type classes, because otherwise you cannot use things like "+" in a deeply immutable function. > I would like to propose deeply-immutable > type class definitions as an alternative. Determining which functions > are deeply immutable should be simple in either case. It's not an either-or situation. The problem at the moment is that there is simply no way to *tell* whether a function is deeply immutable. Swaroop: *if* we introduce DI-FN, this is a case where the unifier should break ties between FN and DI-FN in favor of DI-FN, because DI-FN is strictly more general and this resolution can never break expectations. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
