On Oct 21, 2008, at 6:14 PM, Waldemar Horwat wrote:

Maciej Stachowiak wrote:
I don't think you can represent tail position in a switch statement with your "attribute grammar" notion, but it's clear to me that the statement immediately before a break statement, or else the last statement in the last case or default clause, is in tail position. There is no reason this should be any different than the if/else case.
Regards,
Maciej

Of course, if you do that then you're back to what Dave was complaining about: break becomes like return in that it can jump out of various kinds of places. For example:

switch (x) {
case 1: {
  if (x) {
    g();
    break;
  }
  h();
  break;
}
case 2:
  try {
    h();
    break;
  } finally ...
case 3:
  ...
}


Breaking out of an if seems non-problematic to me, you could imagine rewriting all such if statements where everything after it is in an else clause, and then it would be clear that in case 1 both g() and h() are in tail position (assuming the switch statement itself is). However nothing inside a "try" block can be in tail potion since there is implied control context. That's a problem with "try", though, not with "switch". Obviously wrapping with "switch" cannot turn a non-tail position into a tail position.

You could probably define a rigorous transform to apply to a swtich() statement that turns it into a series of if / else clauses (possibly duplicating later cases if there is no break) and apply the usual if rule to that transform to get case statements into the attribute grammar more formally. For example the above could transform as something like:

if (x == 1) {
    if (x) {
        g();
    } else {
        h();
    }
} else if (x == 2) {
    try {
      h();
    finally ...
    ... // duplicate case 3 assuming there was no break
} else if (x == 3) {
    ...
}

Then it's clear that the first two calls can be in tail position but the third cannot by the usual rules for if(). It doesn't make sense to treat switch differently just because the syntax is different.

Regards,
Maciej

_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to