Syntax enhancements

[cardillan]

I'm pondering on implementing the following syntax enhancements:

Multiple when alternatives in case expressions

Allow more than one expression per case when alternative. Syntax would be identical to Ruby, eg.

case buildingType
  when @battery, @large-battery
    ...
  when @vault, @container
    ....
end

Do-while loop

A standard loop with the condition at the end. Ruby's way of doing this requires the if modifier we still don't have, and while I'd like to do it, I find in difficult to enhance the grammar this way. (Doesn't Ruby consider line endings when discerning if modifier from if statement? For us line endings are just whitespace.) So I propose the following syntax:

do
  loop-body
loop while condition

loop while being keywords. This adds a new keyword, and deviates from Ruby syntax.

For each loop

We don't have arrays or collections, but the list for a for each loop could be efficiently hard-coded into the compiled code and it could be quite useful. It's true that Mindustry 7 lookup function allows to loop over built-in items, but this for each loop wouldn't quite identical. For example:

for UNIT in [@flare, @mono, @poly]
  bind(UNIT)
  if @unit != null break end
end

The compiled code would look something like this:

set iterator flare
label loop_start
set @counter iterator
label flare
set UNIT @flare
set iterator mono
jump loop_body
label mono
set UNIT @mono
set iterator poly
jump loop_body
set UNIT @poly
set iterator loop_exit
label loop_body
ubind UNIT
...
jump loop_start always
label loop_exit

(Loop_start and loop_exit labels support the break and continue statements.) The list would accept expressions, which would be evaluated before the loop begins. It's defined in the Ruby's array syntax, which would make it's definition in grammar quite easy. Normal parentheses could be probably made to work too: for unit in (@mono, @poly) ... end. I like this a wee bit more.

Non-constant ranges

Like current ranges, but allowing expressions in the definition. Constant ranges would be still required for stack and heap allocations, but expression ranges could be used in for loops:

for i in startIndex .. endIndex
    ...
end

and case expressions:

UNUSED = 0
FIRST_STEP = 1
LAST_STEP = 5
case state
    when UNUSED 
       ...
    when FIRST_STEP ... LAST_STEP 
      ...
   else
end

@francois, if there's something you'd want to discuss beforehand, please let me know, otherwise I'd try to implement these enhancements (more or less in the given order).

[francois]

These proposals are good enhancements. You can go ahead with them. FrançoiS

[cardillan]

The new case when syntax allows for quite hard-to spot bugs to occur. For example, in this code

case block.type
	when @overdrive-projector
		block.enabled = OVERDRIVE
	when @conduit, @pulse-conduit, @plated-conduit,
		block.enabled = startup
end

there's superfluous comma at the end of the second when expression list. It still compiles and turns the block.enabled = startup statement into another expression in the when expression list (and the body of that when clause is a NoOp.) The typo is somewhat hard to spot and one (eg. myself 😄) can conclude the compiler is buggy.

I'd try to amend the syntax in this way: if there is more than one expression in the when clause, the entire clause must end with a colon. If there's just one expression, the colon would be optional. The above code therefore wouldn't compile and the correct one would look like this:

case block.type
	when @overdrive-projector
		block.enabled = OVERDRIVE
	when @conduit, @pulse-conduit, @plated-conduit:
		block.enabled = startup
end

Current code (with single expression per branch) wouldn't be affected by this change.

Perhaps a more Ruby-esque way would be to use a keyword, say, then?

case block.type
	when @overdrive-projector then // then optional here
		block.enabled = OVERDRIVE
	when @conduit, @pulse-conduit, @plated-conduit then
		block.enabled = startup
end

Colon looks better to me, but I have spent ages in C-like languages. What do you think, @francois?

[cardillan]

Implemented in the March 2023 update, closing.