Agreed for the second option where the numeric is specified.
I like being able to start at non-zero even tho you’re really saying for example CAST n-x
What is the pasm result? A table of addresses and you add ‘n’ to the base address? It’s sort of like using an XBYTE instruction with the skip bits all zero.
Use JTABLE n-5 in the above example and code for 0... and forget LOWER:
I like JTABLE because it's descriptive.
I preferred the structure of SELECT/CASE until I decided to experiment with ON/GOTO/GOSUB and realised that there was a jump table happening...heck of a lot quicker...great for machine sequences.
I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.
Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.
My preferences...
CASE TABLE x or JTABLE x
with
ELSE:
I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.
Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.
My preferences...
CASE TABLE x or JTABLE x
with
ELSE:
And please, no ELIF:
Is there a need for ELSE?
BASIC's ON/GOTO/GOSUB simply falls through if no match.
CASE TABLE x
1: some simple things to do
2: some other things
3: a little bit more elaborated thing
4: almost nothing
and leaving the compiler to do the job
the programmer now has to define 4 subroutines (we do not expect return values do we?)
for 1: .. 4: with all the overhead?
that will be called from inside CASE TABLE ... ??
CASE TABLE x
1: some simple things to do
2: some other things
3: a little bit more elaborated thing
4: almost nothing
and leaving the compiler to do the job
the programmer now has to define 4 subroutines (we do not expect return values do we?)
for 1: .. 4: with all the overhead?
that will be called from inside CASE TABLE ... ??
Or is any expression valid in the case item body?
No, no. It's simple and looks like a regular case statement. The only caveats are that the 'value :' terms are constants and don't exceed 0..255, which is an arbitrary limitation that I'm placing. Multiple lines of statements can be placed after each 'value :'.
CASE TABLE x
1: some simple things to do
2: some other things
3: a little bit more elaborated thing
4: almost nothing
and leaving the compiler to do the job
the programmer now has to define 4 subroutines (we do not expect return values do we?)
for 1: .. 4: with all the overhead?
that will be called from inside CASE TABLE ... ??
Or is any expression valid in the case item body?
This creates an indexed jump table, not a GOSUB table, in place of a sequence of comparison operations. If there are any other limitations beyond a traditional CASE statement they are yet to be announced.
Taking an example from the SPIN reference:
case X+Y
10, 15: !outa[0]
A*2 : !outa[1]
30..40: !outa[2]
X += 5
'Test X+Y
'X+Y = 10 or 15? Toggle P0
'X+Y = A*2? Toggle P1
'X+Y in 30 to 40? Toggle P2
'Add 5 to X
Produces a set of comparisons like:
If X+Y == 10 or X+Y == 15 then !outa[0]
Elseif X+Y == A*2 then !outa[1]
Elseif X+Y => 30 and X+Y =< 40 then !outa[2]
This CASE TABLE will instead produce a table of addresses with entries like:
0 next instruction
1 next instruction
2 next instruction
3 next instruction
4 next instruction
5 next instruction
6 next instruction
7 next instruction
8 next instruction
9 next instruction
10 !outa[0]
11 next instruction
12 next instruction
13 next instruction
14 next instruction
15 !outa[0]
16 next instruction
17 next instruction
18 next instruction
19 next instruction
20 next instruction
21 next instruction
22 next instruction
23 next instruction
24 next instruction
25 next instruction
26 next instruction
27 next instruction
28 next instruction
29 next instruction
30 !outa[2]
31 !outa[2]
32 !outa[2]
33 !outa[2]
34 !outa[2]
35 !outa[2]
36 !outa[2]
37 !outa[2]
38 !outa[2]
39 !outa[2]
40 !outa[2]
41 next instruction
.
.
.
max table value next instruction
This is one example where the CASE TABLE may not work properly, as A*2 can only be determined at compile time if A is a constant, unless the code then includes more code to update the table entries; probably a case of diminishing returns.
It also shows that for some simple use cases, memory use will be much larger.
But in some use cases it will be the best balance between code simplicity and deterministic behaviour.
I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.
Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.
Chip,
Guess I am now a little confused. I thought that the CASE TABLE x would produce a jump table to addresses. ie there is no possible multiple instructions in the case table statement as can occur in the case statement.
Chip,
Guess I am now a little confused. I thought that the CASE TABLE x would produce a jump table to addresses. ie there is no possible multiple instructions in the case table statement as can occur in the case statement.
Each case can have a block of code in it. The jump table is just how it gets to those blocks.
I'm still not buying the need for a special syntax beyond just case. If a programmer's case block meets the special requirements of the presumptive new keyword, the compiler can emit the special code for it. The only thing that needs to change from the user's standpoint is a note in the Spin docs that adhering to those requirements in their case structures will result in faster, more efficient code.
This is in keeping with the spare syntax of Spin. After all, DO, FOR, and their ilk have all been subsumed by repeat. So let's keep it that way with case without cluttering up the language with a redundant new keyword.
I'd rather ask for a special fast CASE than contrive everything so that (hopefully) the fastest implementation is chosen.
I may be in a Aussie state-of-mind today, but both ACTION and LANE sound good to me. It's too whimsical, but FastLane provides uniqueness and suggests dispatch.
JUMP is a poor choice, because JUMP has no return.
The instance blocks can be in-line, or function calls, or any mix, but the CASE code executes ONE choice and then falls out the end.
The fine print is around how it makes that one-of choice, and to me that does not need a new keyword, and certainly does not need a misnomer keyword.
Either a new word or a modifier is required to “force” the use of a table.
Remember, a table is not always faster, nor shorter code. It’s a deliberate requirement to use a table to keep deterministic timing. Otherwise, timing becomes lopsided depending on the path taken.
So perhaps for consistency with existing CASE command, add the table modifier as in CASE TABLE x or CASETABLE x
BTW I still like ELSE rather than OTHER, so how about permitting both???
Seems every language introduced its own case quirk just to make it different from every other language. IMHO else is easier to remember and more language consistent for newbies.
OT - I have been doing some Python for work. Looked nice, requires indentation. Then I got to ELIF Seriously, are we so lazy we cannot type ELSEIF ?
Then I got to ELIF Seriously, are we so lazy we cannot type ELSEIF ?
Yeah, Perl uses elsif. I've always figured it had something to do with outdated parser/scanner technology seeing the else in elseif and stopping there before scanning the whole word.
JUMP is a poor choice, because JUMP has no return.
The instance blocks can be in-line, or function calls, or any mix, but the CASE code executes ONE choice and then falls out the end.
The fine print is around how it makes that one-of choice, and to me that does not need a new keyword, and certainly does not need a misnomer keyword.
Actually, maybe it'd be nice if you could have something like the "break" in the C++ switch statement?
So, you could combine more options... For example, the "1" case could do both "1" and "2" things if you wanted by leaving off the "break" at the end of the "1" code...
Yeah, Perl uses elsif. I've always figured it had something to do with outdated parser/scanner technology seeing the else in elseif and stopping there before scanning the whole word.
-Phil
Oberon uses ELSIF, and FreeBASIC uses ElseIf
I think the motivation here is not so much laziness, as tab-stop driven users seek shorter words
Comments
SNAP
THAT
How do those grab you?
DOG - the long and thorough version of CASE that smells everything along the way.
CAT - the table version that scrams from point A to point B right away.
when you can have a LEAPTO
I like JTABLE because it's descriptive.
I preferred the structure of SELECT/CASE until I decided to experiment with ON/GOTO/GOSUB and realised that there was a jump table happening...heck of a lot quicker...great for machine sequences.
Why forget LOWER? That seems useful.
Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.
My preferences...
CASE TABLE x or JTABLE x
with
ELSE:
And please, no ELIF:
I think having a keyword to indicate it's the jump table type is fine, makes it easier for the compiler and very clear for the user.
I think, after some thought, that using CASE TABLE x would be best and clear. I still prefer DEFAULT or OTHER, but could live with ELSE if it must be.
CASE TABLE x
OTHER
I agree. I can agree with lots of things, but I think I agree with these the most now.
Is there a need for ELSE?
BASIC's ON/GOTO/GOSUB simply falls through if no match.
the programmer now has to define 4 subroutines (we do not expect return values do we?)
for 1: .. 4: with all the overhead?
that will be called from inside CASE TABLE ... ??
Or is any expression valid in the case item body?
No, no. It's simple and looks like a regular case statement. The only caveats are that the 'value :' terms are constants and don't exceed 0..255, which is an arbitrary limitation that I'm placing. Multiple lines of statements can be placed after each 'value :'.
This creates an indexed jump table, not a GOSUB table, in place of a sequence of comparison operations. If there are any other limitations beyond a traditional CASE statement they are yet to be announced.
Taking an example from the SPIN reference:
Produces a set of comparisons like:
This CASE TABLE will instead produce a table of addresses with entries like: This is one example where the CASE TABLE may not work properly, as A*2 can only be determined at compile time if A is a constant, unless the code then includes more code to update the table entries; probably a case of diminishing returns.
It also shows that for some simple use cases, memory use will be much larger.
But in some use cases it will be the best balance between code simplicity and deterministic behaviour.
To re-iterate:
Guess I am now a little confused. I thought that the CASE TABLE x would produce a jump table to addresses. ie there is no possible multiple instructions in the case table statement as can occur in the case statement.
Each case can have a block of code in it. The jump table is just how it gets to those blocks.
What about "WHEN..IS" ?
WHEN x IS
1: Dothis
2: Dothis
ELSE Dothis
Maybe leave out the "IS" part...
Bean
I'd call it something like LANE - implies things keep moving and in sync (deterministically), but you branch to preferred lane.
Made me think of "YUMP!"
?
Jonathan
So, according to Collins Dictionary, you are thinking about leaving the ground for a short while...
https://collinsdictionary.com/dictionary/english/yump
It also makes me think about Super Mario...
This is in keeping with the spare syntax of Spin. After all, DO, FOR, and their ilk have all been subsumed by repeat. So let's keep it that way with case without cluttering up the language with a redundant new keyword.
-Phil
I may be in a Aussie state-of-mind today, but both ACTION and LANE sound good to me. It's too whimsical, but FastLane provides uniqueness and suggests dispatch.
JUMP is a poor choice, because JUMP has no return.
The instance blocks can be in-line, or function calls, or any mix, but the CASE code executes ONE choice and then falls out the end.
The fine print is around how it makes that one-of choice, and to me that does not need a new keyword, and certainly does not need a misnomer keyword.
Remember, a table is not always faster, nor shorter code. It’s a deliberate requirement to use a table to keep deterministic timing. Otherwise, timing becomes lopsided depending on the path taken.
So perhaps for consistency with existing CASE command, add the table modifier as in CASE TABLE x or CASETABLE x
BTW I still like ELSE rather than OTHER, so how about permitting both???
Seems every language introduced its own case quirk just to make it different from every other language. IMHO else is easier to remember and more language consistent for newbies.
OT - I have been doing some Python for work. Looked nice, requires indentation. Then I got to ELIF
Ugh. please just use CASE TABLE x, like you said you liked. JUMP is dumb.
Also, be sure that it can handle missing numbers, gaps. Like:
in the above example, cases 0..3 and 6..9 would go to the other case.
There would be 15 entries in the table, 0 through 13 plus the other.
-Phil
Actually, maybe it'd be nice if you could have something like the "break" in the C++ switch statement?
So, you could combine more options... For example, the "1" case could do both "1" and "2" things if you wanted by leaving off the "break" at the end of the "1" code...
Oberon uses ELSIF, and FreeBASIC uses ElseIf
I think the motivation here is not so much laziness, as tab-stop driven users seek shorter words