1. 2.6 feature request: foreach
I think that the next release should have something new and useful to the
language. Sure, you could do "continue" or "next" or something but will everyone
use them? When I was looking at all the code I've written I realized that maybe
around half of all my "for" loops were being used to reference each element in a
sequence one after another. Due to this I think that a "foreach" statement would
be a VERY useful addition to the language that I'm sure everyone would use.
It's syntax could go like so:
Instead of
sequence line
line = gets(0)
for i=1 to length(line)
if line[i] = -- something
-- code goes here
end if
end for
One would type
sequence line
line = gets(0)
foreach element in line do
if element = -- something
-- code goes here
end if
end foreach
Here "element" would implicitly be declared as an object and act just like the
current loop variable in "for". However, after every iteration of the loop
"element" will be set to the next next element in "line". A consideration would
be to optimize expressions of the type "foreach obj in reverse(seq)do"
2. Re: 2.6 feature request: foreach
D. Newhall wrote:
>
> I think that the next release should have something new and useful to the
> language.
> Sure, you could do "continue" or "next" or something but will everyone use
> them? When
> I was looking at all the code I've written I realized that maybe around half
> of all
> my "for" loops were being used to reference each element in a sequence one
> after another.
> Due to this I think that a "foreach" statement would be a VERY useful addition
> to the
> language that I'm sure everyone would use.
>
> It's syntax could go like so:
>
> Instead of
>
> sequence line
> line = gets(0)
> for i=1 to length(line)
> if line[i] = -- something
> -- code goes here
> end if
> end for
>
> One would type
>
> sequence line
> line = gets(0)
> foreach element in line do
> if element = -- something
> -- code goes here
> end if
> end foreach
>
> Here "element" would implicitly be declared as an object and act just like the
> current
> loop variable in "for". However, after every iteration of the loop "element"
> will be
> set to the next next element in "line". A consideration would be to optimize
> expressions
> of the type "foreach obj in reverse(seq)do"
>
In the context of a language that has a sequence as its major selling point,
foreach makes a lot of sense.
=====================================
Too many freaks, not enough circuses.
j.
3. Re: 2.6 feature request: foreach
D. Newhall wrote:
> I think that the next release should have something new and useful to the
> language.
> Sure, you could do "continue" or "next" or something but will everyone use
> them? When
> I was looking at all the code I've written I realized that maybe around half
> of all
> my "for" loops were being used to reference each element in a sequence one
> after another.
> Due to this I think that a "foreach" statement would be a VERY useful addition
> to the
> language that I'm sure everyone would use.
>
> It's syntax could go like so:
>
> Instead of
>
> sequence line
> line = gets(0)
> for i=1 to length(line)
> if line[i] = -- something
> -- code goes here
> end if
> end for
>
> One would type
>
> sequence line
> line = gets(0)
> foreach element in line do
> if element = -- something
> -- code goes here
> end if
> end foreach
>
> Here "element" would implicitly be declared as an object and act just like the
> current
> loop variable in "for". However, after every iteration of the loop "element"
> will be
> set to the next next element in "line". A consideration would be to optimize
> expressions
> of the type "foreach obj in reverse(seq)do"
Thanks for the suggestion.
I thought about something like this about 10 years ago.
At first it looked like a good idea, but after trying
various examples and thinking it through, I felt it
might cause confusion. Short simple examples like the one
above are ok, but what if you have a loop with 100 statements
in it? The aliasing of one name for another might be hard to remember.
In the middle of a long section of code you could easily
forget that element = 99 really means (something like) line[i] = 99
(I assume you could read or write these loop variables).
Or element[5] += 1, really means (more or less) line[i][5] += 1
And could you change line in the middle of the loop? Would the
value of line be locked in. What if you saw:
line[j] = element
Would you instantly understand what it meant?
These issues made me think the feature was not
such a good thing to add to a language that is supposed to
be simple.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: 2.6 feature request: foreach
Robert Craig wrote:
>
> Thanks for the suggestion.
> I thought about something like this about 10 years ago.
> At first it looked like a good idea, but after trying
> various examples and thinking it through, I felt it
> might cause confusion. Short simple examples like the one
> above are ok, but what if you have a loop with 100 statements
> in it? The aliasing of one name for another might be hard to remember.
> In the middle of a long section of code you could easily
> forget that element = 99 really means (something like) line[i] = 99
> (I assume you could read or write these loop variables).
> Or element[5] += 1, really means (more or less) line[i][5] += 1
> And could you change line in the middle of the loop? Would the
> value of line be locked in. What if you saw:
> line[j] = element
> Would you instantly understand what it meant?
> These issues made me think the feature was not
> such a good thing to add to a language that is supposed to
> be simple.
>
> Thanks,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Well, since the loop variable when using "for" is read-only I don't see a reason
why "foreach" would have the loop variable read-write. Yes, you are right
"element[5] = 675" would be confusing if it just expanded to "line[i][5] = 675"
since you might not remember what it expanded to but that would make it the only
statement in the langauge that had behavior like that which would probably
confuse people. However, keeping it read-only would keep it in-line with the
current "for" statement and you'd still be able to loop through sequence elements
quickly. Also, why would you need writeability to every element of a sequence
when we already can do operations on every element of a sequence? In many cases
it'd just be redundant and take up more code. If you absolutely did need to do it
you could just do it the way we do it already which would further distinguish
between reading from evrey element of a sequence using a loop and modifying every
one. Yes, it would limit the "foreach" statements power but it would still be
useful.
5. Re: 2.6 feature request: foreach
Robert Craig wrote:
[snip]
> These issues made me think the feature was not
> such a good thing to add to a language that is supposed to
> be simple.
And thus the requirement for a 'better' language than this too-simple one. A
language suitable for coders that are more sophisticated than RDS aims its
marketing at.
Life is too short to ask RDS for anything that helps Euphoria break into
communities that are able to cope with, and utilize, a language that is degree or
two more 'complex' than RDS's programming beliefs.
In short, don't bother asking RDS for enhancements, because how can Euphoria
improve? - its already perfectly simple.
As Albert Einstein has reportedly said ...
"Everything should be made as simple as possible, but not simpler."
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
In my opinion, Euphoria is *too* simplistic rather than too simple, and I
believe that RDS only expects simple coders to use it.
When I started using Euphoria, I was amazed at its versatility and ease of use.
However, it didn't take long to find out that once one starts coding
commercial-quality applications, Euphoria's "simplicity" ensured that the
application code became complex, and thus difficult to read and maintain.
I know that lots of people can show me large Euphoria programs that they say are
well written and easy to maintain, especially when compared with other languages,
and I'd tend to agree with that comparision. However, I find it hard to believe
that with a better Euphoria, that those programs could not be made even cheaper
to maintain and write.
Once again, RDS drives me to frustration! I'm sorry if I've offended anyone.
I'll now go back into semi-retirement again 
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
6. Re: 2.6 feature request: foreach
Jason Gade wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> D. Newhall wrote:
>
>>I think that the next release should have something new and useful to the
>>language.
>>Sure, you could do "continue" or "next" or something but will everyone use
>>them? When
>>I was looking at all the code I've written I realized that maybe around half
>>of all
>>my "for" loops were being used to reference each element in a sequence one
>>after another.
>>Due to this I think that a "foreach" statement would be a VERY useful addition
>>to the
>>language that I'm sure everyone would use.
>>
>>It's syntax could go like so:
>>
>>Instead of
>>
>>sequence line
>>line = gets(0)
>>for i=1 to length(line)
>> if line[i] = -- something
>> -- code goes here
>> end if
>>end for
>>
>>One would type
>>
>>sequence line
>>line = gets(0)
>>foreach element in line do
>> if element = -- something
>> -- code goes here
>> end if
>>end foreach
>>
>>Here "element" would implicitly be declared as an object and act just like the
>>current
>>loop variable in "for". However, after every iteration of the loop "element"
>>will be
>>set to the next next element in "line". A consideration would be to optimize
>>expressions
>>of the type "foreach obj in reverse(seq)do"
>>
>
> In the context of a language that has a sequence as its major selling point,
> foreach makes a lot of sense.
I've been thinking about this and I think Rob is right.
It would be difficult to add foreach into the language without
references as well.
<code>
foreach element in someseq do
-- some statements
end for
</code>
If element was not a reference to someseq, then modifying it would make
no sense without having another sequence as a temporary. Plus you
wouldn't know which index you were at so you couldn't directly modify
someseq.
<code>
for i in someseq do
-- some statements
end for
</code>
Would be a little better but it is just syntactic sugar for
for i = 1 to length(someseq)
-- some statements
end for
There are also more complicated solutions, but they are just that --
more complicated.
I still think it would be a good addition to the standard library project.
Structural changes would have to be made to Euphoria to make it
reasonable as a statement.
--
==============================
Too many freaks, not enough circuses.
j.
