1. [Phix] Language Feature Request: For Each

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.

new topic     » topic index » view message » categorize

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

+1 - I like that

new topic     » goto parent     » topic index » view message » categorize

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

+1 - I like that

new topic     » goto parent     » topic index » view message » categorize

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

euphoric said...

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

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".

euphoric said...
-- 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.

new topic     » goto parent     » topic index » view message » categorize

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

petelomax said...
euphoric said...

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

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 

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).

new topic     » goto parent     » topic index » view message » categorize

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

<reworded/deleted>

new topic     » goto parent     » topic index » view message » categorize

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

euphoric said...

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

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.

euphoric said...

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

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.

new topic     » goto parent     » topic index » view message » categorize

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

  • ''for'' is a keyword; do not overload

python

  • for reference, a Python loop looks like:
for x in mylist: 
   print(x) 

this is a clever way to hide the mess created by off-by-one indexing

suggested new feature

  • the OE/Phix equivalent could look like
each <item> in <sequence> do 
   <... statements> 
end each 

sample usage

  • simulate the existing ''for'' loop
each {i} in  {"one","two","three"} do 
   ? i 
end each 

1 
2 
3 

  • simulate Python loop
each {i,x} in  {"one","two","three"} do 
   ? x 
end each 

"one" 
"two" 
"three" 

  • demonstrate Euphoria thinking
each {i,key,value} in {{"eins","uno"}, 
                        {"dwei","duo"}, 
                        {"drei","tres"}} do 
    ? key 
    ? value 
    ? "---" 
 
end each 

"eins" 
"uno" 
"---" 
"dwei" 
"duo" 
"---" 
"drei" 
"tres" 
"---" 

multiple assignment paradigm

the ''each'' statement implies

 
{ i, key, value } := { 3, "drei", "tres" } 
 
                       ^   ================= element as a flat sequence 
                       |                  
                   index 

be well _tom

new topic     » goto parent     » topic index » view message » categorize

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

petelomax said...
euphoric said...

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

There has to be an index (how else do you suggest it iterates down a sequence?),

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...

new topic     » goto parent     » topic index » view message » categorize

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

my typing is slow...

  • a flaw in the Python model is you do not have access to the index
  • second flaw, is off-by-one indexing

I find the index handy because sometimes I want to "look ahead" or "look behind" the element currently selected ... therefore I sometimes need the index.

this ''each'' version uses existing OE/Phix syntax

be well

new topic     » goto parent     » topic index » view message » categorize

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

_tom said...

sample usage

  • simulate the existing ''for'' loop
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.

new topic     » goto parent     » topic index » view message » categorize

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

euphoric said...
petelomax said...
euphoric said...

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

There has to be an index (how else do you suggest it iterates down a sequence?),

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...

  • { i, key, value }

does give you a user facing index

  • if you follow the pattern

{} implies do not enter the loop

be well _tom

new topic     » goto parent     » topic index » view message » categorize

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

_tom said...
  • a flaw in the Python model is you do not have access to the index

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 
_tom said...

I find the index handy because sometimes I want to "look ahead" or "look behind" the element currently selected ... therefore I sometimes need the index.

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.

new topic     » goto parent     » topic index » view message » categorize

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

euphoric said...
_tom said...

sample usage

  • simulate the existing ''for'' loop
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.

  • yes, it is sugar
  • yes, it avoids standard boiler plate

your observation shows that a novice would recognize the "each" and "for" statements as being related

be well

new topic     » goto parent     » topic index » view message » categorize

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

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?).

new topic     » goto parent     » topic index » view message » categorize

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

consider expanding the ''in'' pattern

sequence s = {"one","two","three"} 
 
while ( x in s ) do 
    ? x 
end while 

"one" 
"two" 
"three" 

for (x in s ) do 
new topic     » goto parent     » topic index » view message » categorize

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

_tom said...
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...?

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu