Also, does adding OTHER entail a 256-entry long jump table to accommodate determinism for the OTHER option, too?
-Phil
OTHER is a separate matter from the table that always picks up the no-match cases. It won't cause the table to be maximally-, or even differently-, sized.
I don't think it's that simple. If the user writes
case table
did they mean to do a "case x table" statement but forgot the "x", or did they really mean to do a "case" statement with variable "table"?
That would depend, of course, on whether table was declared as a constant or variable -- an easy check for the compiler to perform.
It's still ambiguous, even if it was declared as a variable -- the user may simply have forgotten to type the variable they really meant.
Also, compilers are often written in passes, the first of which (the lexical analyzer) is tasked with identifying keywords and which doesn't know about variables.
In any event, I have little sympathy for compiler writers who want to make their tasks easy, when the overriding objective should be to make the programmers' tasks easy and the language simple, clear, and elegant. A compiler only has to be written once; programs compiled with it could run in the millions of instances.
There's no need to make the compiler writers' job any harder, either. Why not use "CASE_FAST" (introducing a new keyword unlikely to conflict with any existing one) or "CASE JMP" (re-using an existing keyword)? They're just as clear, and are easier to parse.
I think this thread has amply demonstrated that we're never going to get everyone to agree, so I think the guy who's actually implemening the compiler should pick the option that's best for him.
Could the compiler spot the existing case statement being used with only sequential constants and make it an optimization to implement it that way?
This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.
As posted earlier, fastspin already does this (both the CASE optimization and the CONSTANT optimization) I don't think Chip wants to add that compexity to his Spin2 compiler right now, but perhaps it'll be implemented later (or perhaps fastspin will implement output of Spin2 bytecodes rather than PASM someday).
This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.
Automatic constant folding in Spin2 would be a blessing, as would automatic promotion of simple, multi-character strings to their addresses. Of all the inconveniences in Spin, constant and string have to rank pretty high.
-Phil
Addendum: Come to think of it, just replacing string with @ would solve the string problem, and make it crystal clear to the programmer that an address was being returned.
I don't think it's that simple. If the user writes
case table
did they mean to do a "case x table" statement but forgot the "x", or did they really mean to do a "case" statement with variable "table"?
That would depend, of course, on whether table was declared as a constant or variable -- an easy check for the compiler to perform.
In any event, I have little sympathy for compiler writers who want to make their tasks easy, when the overriding objective should be to make the programmers' tasks easy and the language simple, clear, and elegant. A compiler only has to be written once; programs compiled with it could run in the millions of instances.
That's the way, code monkeys dump on the compiler engineers, who dump on systems engineers, who dump on chip engineers, who dump on fabrication engineers. And everyone dumps on the scientists.
Comments
OTHER is a separate matter from the table that always picks up the no-match cases. It won't cause the table to be maximally-, or even differently-, sized.
Will you be publishing a formal grammar for Spin2? There wasn't one for Spin, which complicated things for others wanting to write a compiler for it.
Thanks,
-Phil
Yes. It's almost to the point where I can do that. I just need to get it running and make sure it's all sensible.
https://github.com/totalspectrum/spin2cpp/blob/master/frontends/spin/spin.y is pretty close, I think.
Also, compilers are often written in passes, the first of which (the lexical analyzer) is tasked with identifying keywords and which doesn't know about variables.
There's no need to make the compiler writers' job any harder, either. Why not use "CASE_FAST" (introducing a new keyword unlikely to conflict with any existing one) or "CASE JMP" (re-using an existing keyword)? They're just as clear, and are easier to parse.
I think this thread has amply demonstrated that we're never going to get everyone to agree, so I think the guy who's actually implemening the compiler should pick the option that's best for him.
This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.
As posted earlier, fastspin already does this (both the CASE optimization and the CONSTANT optimization) I don't think Chip wants to add that compexity to his Spin2 compiler right now, but perhaps it'll be implemented later (or perhaps fastspin will implement output of Spin2 bytecodes rather than PASM someday).
-Phil
Addendum: Come to think of it, just replacing string with @ would solve the string problem, and make it crystal clear to the programmer that an address was being returned.
+1