Re: Switch/Case with Fallthrough

[Paige DePol <lual@...>]

> On Nov 20, 2013, at 12:20 PM, Sean Conner <sean@conman.org> wrote:
> 
>  With "break", it's not quite the same as an if/elseif/else block.  For
> instance (first example):
> 
> 	switch(x)
> 	  case 1
> 	    print("foo")
> 	    break
> 	  case 2
> 	    print("bar")
> 	    break
> 	  else
> 	    print("wtf")
> 	end
> 
> *is* the same as:
> 
> 	if x == 1 then
> 	  print("foo")
> 	elseif x == 2 then
> 	  print("bar")
> 	else
> 	  print("wtf")
> 	end

Yes, I don't think anyone is disputing that fact! ;)

Well, it is not exactly the same as with the switch X is loaded into a local variable at the start of the switch, which mean if X was a global variable then the if/elseif's would be loading the global at each comparison versus the one load for the switch.


> But this:
> 
> 	switch(x)
> 	  case 1
> 	    print("foo")
> 	  case 2
> 	    print("bar")
> 	  else
> 	    print("wtf")
> 	end
> 
> is more like:
> 
> 	if x == 1 then
> 	  print("foo")
> 	end
> 	if x == 1 or x == 2 then
> 	  print("bar")
> 	end
> 	-- ... um ... is "wtf" always printed?

Yes, but obviously in this case the switch statement makes it far clearer as to what is going on.

Also, yes in your example above the else block would always be executed as you have no break statements at all, so everything will just fall through to the end of the switch. As should be expected and is also how it would work in C.


>  Okay, if each case has a "break" statement [1] then an optimization might
> be to convert the switch statement to a table.  Go, going back to my first
> example, it would internally be converted to: {snip}

Your examples involve the use of tables and functions, both of which are unnecessary overhead that I would not want to incur for every switch statement that is used. Actually, I am unsure how that would qualify as an optimisation really? The current patch is pretty much equal in bytecode to an if/elseif/else construct, and even better when globals are used. When the jump table is implemented I expect much better bytecode savings.


>  Mind the gap!

LOL, indeed I will. I used to live in London and took the Underground a lot so heard "Mind the Gap" daily! ;)


> 	switch(x)
> 	  case 10 ... break
> 	  case 20 ... break
> 	  case 100 ... break
> 	end
> 
>  Or even ... Mind the type!
> 
> 	switch(x)
> 	  case true ... break
> 	  case nil  ... break
> 	  case 10   ... break
> 	  case "foobar" ... break
> 	  case print ... break
> 	end

By offset, by the way, I did not mean the literal value of the constant, but rather the offset it has into the constant pool. Even there there may be gaps, but they would be considerably more manageable and the problem can be easily solved by chaining OP_JMPTBL opcodes.


> [1]	That is, if you keep that syntax.  The number of times I've *not*
> 	used "break" in C code I can cound on the fingers of one hand and
> 	still have a few fingers left over.  It might be better to have a
> 	"fallthrough" statement.

Actually, for Lunia the default is going to break at the end of each case and if you want to fall through to the next case you would use the "continue" keyword... which I already have implemented for loops, so may as well re-use the keyword for my jump table select/case! 

Thanks for your feedback! :)

~pmd~