OpenEuphoria

Re: [Phix] Language Feature Request: For Each

• Posted by petelomax Dec 10, 2021
• 1368 views

I wrote some design notes two years or so ago and reached the conclusions that
1: "in" [along with the optional-ish ','] suffices, there is no need for "each" or "as"
2: there should not be an index-less form (more on that below)
3: After two years no further movement, so don't be expecting this anytime soon.
4: I will also have to revisit all of this with my p2js hat on.

Instead of (assuming "do" ommission was accidental)

for each key as string in {"one","two","three"} do 
for each id as integer in {2,4,6} do 
for each key as object in {"Hello",3,{1,2,3}} do 
for each key as string in all_keys do 

I was thinking

for i, string key in {"one","two","three"} do 
for i, id in {2,4,6} do 
for i, object key in {"Hello",3,{1,2,3}} do 
for i, string key in all_keys do 

and also

for integer i, string key in {"one","two","three"} do 
for integer i, id in {2,4,6} do 
for integer i, object key in {"Hello",3,{1,2,3}} do 
for integer i, string key in all_keys do 

to explicitly state that i must not pre-exist (as well as explicitly type it).
Notice how id "inherits" the integer type in both cases, that is when not overidden.

I decided against allowing an index-less form since it is needed internally anyway and might be helpful in an ex.err,
plus one thing such loops should certainly never do is implicitly modify the corresponding element, otherwise
all_keys or even the constant {"one","two","three"} magically becomes something else. Should you actually want
that sort of behaviour you should have to explicitly code (say) all_keys[i] = key.

Mind you, I've not debated that with anyone, and when(/if ever) I get round to implementing this,
I will no doubt try/test for integer /*i*/, <type> e..., and maybe change that decision.
In fact I've only just realised that <type> "in" suffices just as well as my original ',' "in".

One other case I considered was given say enum up, down, left, right then:

for d in {up, down, left, right} do 

would become, because (w/o the ,e part) it checks that up..right form a contiguous range and complains if not
(ie should you want to do them in a different order or omit any or use any non-constants, you need the ,e part)

for d=1 to 4 do 

as in "no building a sequence and no subscripting, just compile-time checks and searchable/more intuitive code".

-- or next 

If you mean replace "end for" with "next", that's a firm "no thanks" from me.
It adds no value, damages the balance of the language, messes up parsing, syntax colouring (in at least seven completely different places), reindentation, Ctrl [ and Ctrl ] in Edita and Edix, translation to js, and probably more.