[bitc-dev] RFI: deeply immutable functions
Jonathan S. Shapiro
shap at eros-os.org
Thu Aug 11 16:02:19 EDT 2005
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
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
More information about the bitc-dev