[bitc-dev] RFI: deeply immutable functions

M. Scott Doerrie mdoerri at cs.jhu.edu
Thu Aug 11 16:59:52 EDT 2005


Swaroop Sridhar wrote:

> M. Scott Doerrie wrote:
>
>> Jonathan S. Shapiro wrote:
>>
>>>
>>> There is no intrinsic problem in the type system with this
>>> instantiation, but it has an unpleasant consequence: deeply immutable
>>> procedures cannot invoke methods because they may later be instantiated
>>> in a way that violates deep immutability.
>>>
>>>  
>>>
>> How do type classes propagate over interfaces?
>> If type class instances can propagate over the interface boundary 
>> without being defined in the interface, then I agree that additional 
>> syntax is needed.
>
>
> I am not sure what you mean by propagation of type-classes. If what 
> you mean is that some methods of an instantiation are defined in other 
> interfaces/modules, this should certainly be true.

Yes, but do they propagate with or without declaration in the interface 
definition?  I would think that they don't.  So I'm arguing that this 
case can not arise without programmer consent.

I could not cause this to happen with an (import ...) statement.  It 
could only occur with an (import! ...) statement.  This should give 
programmers a way to use interfaces which are only deeply non-mutating.

However, I think I may be digressing, focusing on only one case of a 
larger problem.  This problem could arise locally as well as across 
interfaces.  The di-fn type is a better solution.

>
>>
>>> 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.
>
>
> No. di-fn declaration in a type-class can only be satisfied by a di-fn 
> definition. The compiler will make sure that all di-fns are deeply 
> non-mutating at the time (actually place) of definition.

Ok, I hurridly misread this.  The di-fn type is a more general 
solution.  Somehow I had read constructor.

Would this mean that di-fn is itself some sort of type class?  (di-fn 
T.arg T.result) should be usable where (fn T.arg T.result) is required.  
Of course, this isn't expressible in the current system as our type 
classes only involve methods of fn types.  This is probably incorrect, 
but could we think of di-fn as the following:

(deftypeclass (di-fn 'a 'b)
    (super (fn 'a 'b)))

Of course, this is not user-definable as it's a known type to check for 
deep imutability in the compiler.

Scott Doerrie



More information about the bitc-dev mailing list