Jonathan S. Shapiro wrote:
>>> but I have absolutely no useful thoughts for what to call
>>> top-copy-compat.
>> What is it intended to be useful for?
> 
> In practice, I don't expect most users to use it at all. It is needed
> internally by the complete inference system. 
> 
> Swaroop: can you send out a real-world example?

The top-copy-compat is a relation between two types that can differ in
the outer-most mutability. This constraint gives fine grained control to
specify types that are variable over mutability.

For example, if we want to specify the type of a function that receives
a reference to a pair whose components must be of fixed type (say
(int32, bool)) but we don't care whether the pair itself is mutable or
not. Using top-copy-compat, we can specify a type that is polymorphic
over the mutability of the pair type. For example:

(define (f x) x^.fst:int32 x^.snd:bool ())
f: (forall ((top-copy-compat 'a (pair int32 bool)))
       (fn ((ref 'a)) ()))

We cannot permit full copy-compat here, because the type
f: (forall ((copy-compat 'a (pair int32 bool)))
       (fn ((ref 'a)) ()))

permits the application (f y:(ref (pair (mutable int32) bool)))
which violates the typing of x^.fst:int32

>> If it is obscure enough that conciseness doesn't matter, I suggest
>> MutationInsensitivelyCompatible.
> 
> Unfortunately, I suspect it is not quite that obscure. I have asked
> Swaroop to send out an example where it arises.
> 
> The closest I have come to something seems OK is:
> 
>   Mutable?
> 
> With the '?' indicating optionality rather than predication. My main
> concern is that '?' is used by convention to mean predicates elsewhere
> in LISP-like languages. Predicates do not usually appear in types,
> however, so maybe this is okay here.

I think Mutable? is a fine name because:

i) The type (mutable t) also refers to top-level mutability only
ii) The capitalization in Mutable and the ? mark clearly differentiates
     it from the mutable type constructor.

Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to