On Mon, Jul 21, 2014 at 10:45 PM, Raoul Duke <[email protected]> wrote:
> > Fair enough. But in this case the impediment is well-motivated and > > insurmountable. Real programs require joins. Linear types do not permit > > joins. > > (i'll hope to go really read and learn enough about types to know how > to parse that, since google didn't tell me what "joins" are in this > context, so i can learn if linear typing is therefore silly in e.g. > ats :-) > Sorry. Let me try to give you a sketch. Linear types work very well when you have a sequence of actions. They tend to break down when you have alternative paths. You need to have one "definitive" reference at all points, but the "fork" at the if/then/else cause two to exist. And then at the bottom there is a join after the if/then/else when the linear item returns to the unconditional control path. Now you can discharge your way out of an if/then/else and deal with that case. And it's a bit easier still when if/then/else is an expression (i.e. when you're in an expression language). But throw some procedure calls in there and the analysis gets hairy quickly, and the compiler is enforcing these constraints that the programmers can't track, and pretty soon the developers throw up their hands. That's basically how <a certain project I can't name> ended up throwing them out. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
