On Mon, Feb 16, 2015 at 4:35 PM, William ML Leslie < [email protected]> wrote:
> I had taken the time to formalise a few other possibilities, but decided > I didn't like them. Right now, I want: > > Option 3 (similar to option 1): > > There's some syntax to allow expression of native arities within types, > whether grouping arguments into tuples, wonky arrows, numbers, or an effect > monad. These have no consequence for copy compatability, besides their > influence on the regions involved. > I'm not quite sure where this note stands in our conversational timeline at this point, but I want to note that the "no consequence for copy compatibility" goal is not achievable. Copy compatibility has to apply at concrete types. If two concrete types do not match w.r.t. arity, then we have to fabricate a lambda to deal with that. Fabricating a lambda introduces implicit allocation. That's a "no no". I'm certainly willing to consider syntax that expresses the user's *intent* to permit that lambda, and to construct the lambda implicitly once intent has been established, but we can't quite get to what William is saying above. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
