[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: The meaning of 'sugar' [Forked from Re: Why do we have ipairs?]
- From: Paige DePol <lual@...>
- Date: Wed, 11 Jun 2014 19:31:03 -0500
On Jun 11, 2014, at 7:47 AM, Roberto Ierusalimschy <email@example.com> wrote:
>> However, by the logic you're following, are closures sugar for objects? I'd
>> think you'd say 'no', but then where do you draw the line?
>> When something does exactly the same thing as something else, but in a less
>> verbose (and usually more obfuscated) way, then it is sugar. Sugar is
>> syntactic. That's why it's called "syntactic sugar"
> Probably I am missing something, because I fail to see what in a
> conventional switch statement (for a language like Lua) could be
> different than sugar for a chain of if-elseif-else (unless you
> are talking about "fall through", in which case you should use
> (I also fail to see how closures could be sugar for objects, but this is
> somewhat out of topic here.)
> -- Roberto
I provided a patch a little while ago which adds a fully featured switch statement to Lua, which is NOT sugar for a chain of if-elseif-else statements, and supports "fall through". It essentially uses a table to link the constant for the switch statement and the PC offset of the jump, it also works on a per-block basis so switch statements can be properly nested.
Interestingly, since we are on the topic of sugar, my patch is really a patch to add a type of computed goto to Lua, the switch syntax is actually sugar for the computed goto feature.
Under benchmarks my switch statement was even faster than three chained if/else statements, and tied on two. So, I would say that there is an advantage to implementing a switch statement for Lua, especially for time-critical code were many options must be compared.