OpenEuphoria

1. [Phix] Language Feature Request: For Each

• Posted by euphoric (admin) Dec 10, 2021
• 1564 views

How about a For...Each...End For?

for each key as string in {"one","two","three"} 
   ?key 
end for -- or next 

for each id as integer in {2,4,6} 
   ?key 
end for 

for each key as object in {"Hello",3,{1,2,3}} 
   ?key 
end for 

all_keys = getd_all_keys(myDict) 
for each key as string in all_keys 
   ?key 
   ?getd(key,myDict) 
end for 

Etc.

3. Re: [Phix] Language Feature Request: For Each

• Posted by begin Dec 10, 2021
• 1519 views

+1 - I like that

5. Re: [Phix] Language Feature Request: For Each

• Posted by euphoric (admin) Dec 10, 2021
• 1483 views

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 

Why "for i"? (It seems redundant.)

Should simply be:

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

"key" takes on the value of, not the pointer to, the element in the sequence it is iterating, so the iterable sequence never gets changed in this.

Javascript's forEach() is definitely interesting, but is a method on a class (it seems), so not analogous to Phix's version (it seems).

7. Re: [Phix] Language Feature Request: For Each

• Posted by petelomax Dec 13, 2021
• 1363 views

Sigh. I already explained this in detail above. Let me try again:
There has to be an index (how else do you suggest it iterates down a sequence?),
so I may as well force you to give it a name, and as a bonus show it in the ex.err,
plus it avoids the almost inevitable "so how do I modify all_keys then?" questions.
I'll take another look at hiding it/making it "optional" when/if ever implemented.

JavaScript's Array.forEach() is 96% slower than a plain for loop and requires an iterator which is inherently tied to the defining scope, plus there is no String.forEach() method.
(Note that p2js does not use JavaScript Objects at all, since despite their {} syntax they are far closer to dictionaries than Phix sequences, for which it uses [faster] Arrays.)
The Phix method would just be a shorthand anyway, and hence p2js would just slap out a longhand version, should I ever get round to it.

9. Re: [Phix] Language Feature Request: For Each

• Posted by euphoric (admin) Dec 13, 2021
• 1357 views

I guess I'm not sure why it has to be user-facing. Sure, you have an index behind-the-scenes, but I, as a user, don't ever need it with this construct.

See tom's Python example. No user-facing index variable...

11. Re: [Phix] Language Feature Request: For Each

• Posted by euphoric (admin) Dec 13, 2021
• 1353 views

each {i} in  {"one","two","three"} do 
   ? i 
end each 

1 
2 
3 

I guess it's really just syntactic sugar.

sequence s = {1,2,3,4,5} 
integer i = length(s) 
for x=1 to i do 
  ?s[x] 
end for 
 
-- vs 
 
sequence s = {1,2,3,4,5} 
each i in s do 
  ?i 
end each 
 
-- each without specifying iterating variable type is default object 
sequence s = {1,2,3,4,5} 
each integer i in s do 
  ?i 
end each 
 

Each one produces the exact same output.

13. Re: [Phix] Language Feature Request: For Each

• Posted by euphoric (admin) Dec 13, 2021
• 1323 views

That's not a flaw; it's by design. This isn't the loop you use if you want the index. (Or use your own index...)

integer c = 1 -- if you want the index, here you go 
each i in {1,2,3,4,5} 
  ?i 
  c+=1 -- increment the index 
end each 

In that case, you would not use each. You would use for. Each is syntactical sugar for a for loop where you don't need the index, just the item at the index.

15. Re: [Phix] Language Feature Request: For Each

• Posted by petelomax Dec 17, 2021
• 1219 views

OK, First off I concede, must try harder to allow an optionally anonymous iterator/control var (we'll see).

On "overloading for": Compared to

    for i=1 to n do 

I don't consider

    for i=1 to n by 2 do 

to be any form of overloading, and likewise

    for e in s do 

is equally not what I would really consider overloading [or particularly confusing] either.
There may however be a case for a new construct to iterate over a dictionary, say, and
that would probably justify a different keyword, I'll tentatively reserve "each".
(Noting that dictionaries do not have any syntatic sugar at all to help with them, as yet.)

I have spent the last couple of days seriously considering such monstrosities as

    for string s, integer n in {"one",1,"two",2} by 2 do 
    for {string s, integer n} in {{"one",1},{"two",2}} do 
    for {string s, t} in {"one","uno","two","duo"} by 2 do 
    for {string s, t} in {{"one","uno"},{"two","duo"}} [by 1] do 
    for {string s} in {"one","two"} by 1 do -- (crashes?) 
    for string s in {"one","two"} [by 1] do -- (ok?) 
    for {string s} in {{"one"},{"two"}} [by 1] do -- (ok?) 
    for i,j,k in {1,2} by 2 do -- (iterator + 2*elements???) 
    for j,k in {1,2} by 2 do -- (erm, anonymous iterator???) 

However the bit between "for" and "in" cannot be dynamic like the "by" can anyway,
(I started having weird ideas that "by 2" etc should start chopping out slices...)
and it is probably better to keep the former simple/single var, with eg:

    sequence en_sp = {"one","uno","two","duo"} 
    for i,string s in en_sp by 2 do 
        string t = en_sp[i+1] 
    -- or 
    for en_sp in {{"one","uno"},{"two","duo"}} do 
        {string s, t} = en_sp 

being the way to go and perfectly sufficient and far better than trying to squidge
different constructs between the "for" and "in" with iffy "by" handling. Thoughts?

I am now thinking that a (non-1) by clause precludes an inline literal constant,
since it would make all the intermediate elements completely inaccessible.

Lastly it is now abundantly clear the "element" should default to object type,
it would just be pointless and far too annoying to have it be anything else.
Likewise, it now obviously must be allowed for e to pre-exist or not (wwit?).

17. Re: [Phix] Language Feature Request: For Each

• Posted by petelomax Dec 17, 2021
• 1166 views

while ( x in s ) do 

I would intuitively assume that meant/was the same as

while find(x,s) do 

and expect others would do too...?