OpenEuphoria

Re: [Phix] Language Feature Request: For Each

• Posted by petelomax Dec 17, 2021
• 1034 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?).