The exception syntax added in #1450 has one particularly confusing property: the variable used to receive the exception payload is not binding. So code like this becomes possible to write:
exception ExampleException : 1;
fun f() { throw ExampleException 1; }
fun g() {
var 1 x = 0;
var 1 y = 0;
try
y = f()
catch ExampleException => x { // this is not a binding occurrence of x! it's the same x as is defined above
y = x + 1;
}
return x + y; // returns 3, where one might expect 2 if the outer x was shadowed
}
I propose to change the semantics of Call so that the variable in exception handler clauses becomes a binding occurrence.
The wordLang mechanism we target still works like above, so somewhere between pan, crep and loop the compiler can invent a fresh name for storing the exception and wrap it around the Call. I'm not sure where the best place to do this would be. Doing it in pan_to_crep probably means some headache with shapes, and doing it lower down means more languages need to have their semantics changed.
The exception syntax added in #1450 has one particularly confusing property: the variable used to receive the exception payload is not binding. So code like this becomes possible to write:
I propose to change the semantics of
Callso that the variable in exception handler clauses becomes a binding occurrence.The
wordLangmechanism we target still works like above, so somewhere betweenpan,crepandloopthe compiler can invent a fresh name for storing the exception and wrap it around theCall. I'm not sure where the best place to do this would be. Doing it inpan_to_crepprobably means some headache with shapes, and doing it lower down means more languages need to have their semantics changed.