Evaluation order of cases about pluto

[Sainan]

Mind you that the website documentation is not like a language standards document which has to "define behaviour" or have "undefined behaviour."

I think your given example code is nonsensical due to having multiple cases with the same condition, and it's reasonable to assume that this is undefined behaviour and the compiler has the right to optimise this in some ways. In this case, the compiler does optimise it — maybe for a different reason than why the code is nonsensical — but it has the right to do so either way.

Pluto should maybe raise a warning for the duplicate switch case so you could fix your code (because, again, it's clearly nonsensical) as was already mentioned in #649, although it was kind of forgotten about.

[XmiliaH]

The example is obviously nonsensical, it should just show the point. Maybe it would have been better to replace the last case with a call to some random function which could or could not return 1.

[Sainan]

I get that casecond allows function calls, and we made sure to make the switch blocks flexible like that, but when it comes to optimisations, it has to be based on real-world considerations, and people simply don't write this kind of code. And if they did, I would say the compiler is right to have done the optimisation because your code made certain implications.

I would document this as a "pitfall", but I don't feel like such theoretical code is enough to justify that.

[XmiliaH]

I would be happy about some form of notice that the order is up to the compiler and that cases can be optimised fully out.

This would actually very nice for an optimisation for the switch statement I was writing. It would allow to move all the constants up and test them first with a table lookup to map each case to an integer and do a binary search to make switches O(log n) and then test in linear time the dynamic cases.

[Sainan]

I will reiterate that the website documentation is not a standards document, but I will also point out that at no point is it guaranteed that the conditions are evaluated in the order they are written, and I think the general expectation kind of is that the compiler can and will reorder them if it helps it execute the code faster; the optimisations just have to work as expected in all the "real-world" cases.

[XmiliaH]

There we disagree. I have the expectation (especially for dynamic languages) that things are executed from top to bottom, left to right if not specified otherwise. Maybe this is caused by the languages I have seen.

Furthermore, I would not expect a compiler to just optimise away expressions with side effects, as done here with casevalues that map to default.

Note that this is just my view and others might differ, but there might be other developers out there wo have the same view and for them it would be nice to have a notice that the order is not defined and the default case is executed if none of the other cases that map to non-default cases are true.

[Sainan]

Well, what I have been doing professionally for the last couple of years is C++ and there switches are just notoriously well-optimised and result in pretty unpredictable code. Ideally, we would like to have the same happen with Pluto generating Lua bytecode. And with this as a guideline, we can see that in this case, it's actually an error:

switch (1) {
case 1: default: printf("1 alpha\n"); break;
case 1: printf("1 beta\n"); break; //  error : duplicate case value '1'
}

and forget about calling functions inside of the case conditions...

So, I think Pluto is in a bit of a weird situation, where the kind of optimisations that happen to the switch blocks are actually observable due to how flexible they were designed. Maybe we will have to compromise on either the flexibility or the optimisations, but right now I don't see an issue with having both.