On Tue, Dec 23, 2014 at 10:32 AM, Matt Rice <[email protected]> wrote:
> I've thought it would be nice if the mutability inference could output > a mutation specification, which can then be the input for subsequent > compilations to check against, > That's one possibility, or another would be an IDE that provides some visual indication of mutability status. > though I'm still a bit fuzzy on the details of how to work with a > mixture of annotated and inferred code, at least in the language I was > thinking about this in, the lack of annotations can either mean > immutable (that is immutable by default), or whatever is inferred... > Not particularly happy with that situation to be honest The inference resolution in BitC is that it's immutable unless inferred to be mutable. Things do get a bit more interesting when a parameter is given a parametric type. What mostly happens in that case is that the *interior* type is inferred based on what the procedure actually *does* with the parameter, and then the *exterior* parameter type is whatever it copy-compatible with the inferred interior type. The end result is that mutability doesn't propagate where it doesn't need to. I think we got this wrong, in the sense that I now believe that type variables for mutability should be distinct from other type variables. I'm just concerned that we're likely to end up with too many classes of type variables. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
