1. case and foreach
- Posted by codepilot Gmail Account <codepilot at gmail.com>
Mar 31, 2005
-
Last edited Apr 01, 2005
Pros
I think foreach could be used to add some parallelism to euphoria and
simplify a few things that for loops and subscripting are used for.
Case would be good for simplifying if/elsif/else blocks to a more
manageable level and could also help in optimization.
Cons
Does anyone have something against case or foreach(element in a
sequence) in euphoria?
?
Daniel
2. Re: case and foreach
- Posted by cklester <cklester at yahoo.com>
Mar 31, 2005
-
Last edited Apr 01, 2005
codepilot Gmail Account wrote:
>
> Pros
> I think foreach could be used to add some parallelism to euphoria and
> simplify a few things that for loops and subscripting are used for.
> Case would be good for simplifying if/elsif/else blocks to a more
> manageable level and could also help in optimization.
>
> Cons
> Does anyone have something against case or foreach(element in a
> sequence) in euphoria?
I use the for...each construct a lot in my VBA programs. However, that's
because I can iterate through objects. For example:
dim tbl as Table
for each tbl in ActiveDocument.Tables
'... manipulate the data
next
Since Euphoria doesn't have objects, I don't see how this would be more
useful than what's already available.
for each x in 1 to 50 do
?x
end for
Although it would work for iterating through sequences...
sequence s
s = {1,2,3,4,5}
for each x in s do
?x
end for
Do any of the OOP libraries out there use this construct to loop through
objects in a class/library/whatever?
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
3. Re: case and foreach
- Posted by Tommy Carlier <tommy.carlier at telenet.be>
Mar 31, 2005
-
Last edited Apr 01, 2005
codepilot Gmail Account wrote:
> Pros
> I think foreach could be used to add some parallelism to euphoria and
> simplify a few things that for loops and subscripting are used for.
> Case would be good for simplifying if/elsif/else blocks to a more
> manageable level and could also help in optimization.
>
> Cons
> Does anyone have something against case or foreach(element in a
> sequence) in euphoria?
I also think foreach would be a great advantage. It doesn't only allow
for cleaner code, but could also greatly enhance performance by optimization:
compare these 2 equivalent pieces of code:
1:
sequence s = ...
object x
for i = 1 to length(s) do
x = s[i]
...
end for
2:
sequence s = ...
foreach x in s do
...
end foreach
Using foreach, you can eliminate the index checking (1 <= i <= length(s)).
One suggestion: you can perfectly use the 'for' keyword, instead of adding
a new keyword 'foreach'. Example:
for x in s do
...
end for
--
The Internet combines the excitement of typing
with the reliability of anonymous hearsay.
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
4. Re: case and foreach
- Posted by Jason Gade <jaygade at yahoo.com>
Mar 31, 2005
-
Last edited Apr 01, 2005
I've thought about foreach and I don't really think that it needs to be added to
the language because it can be done with a function or procedure.
foreach(list_of_stuff, routine_id(some_action))
or
list_of_stuff = foreach(list_of_stuff, routine_id(some_action)) --Prefer pass by
reference or optimization of this case
But it is something that could be helped by having pass by reference and an
eval() function.
One problem with a built-in foreach -- does it only iterate the top level of a
sequence or does it dig down through sub sequences? I think that is one reason
to leave it as a procedure or function.
=====================================
Too many freaks, not enough circuses.
j.
5. Re: case and foreach
Jason Gade wrote:
>
> I've thought about foreach and I don't really think that it needs to be added
> to the
> language because it can be done with a function or procedure.
>
> foreach(list_of_stuff, routine_id(some_action))
>
> or
>
> list_of_stuff = foreach(list_of_stuff, routine_id(some_action)) --Prefer pass
> by reference
> or optimization of this case
Thing is, this puts the loop and the code inside the loop in different places
making the code harder to read. Imagine how eu code would be if the for loop
was implemented the same way, as a function or procedure! Spaghetti-code.
> But it is something that could be helped by having pass by reference and an
> eval()
> function.
>
> One problem with a built-in foreach -- does it only iterate the top level of a
> sequence
> or does it dig down through sub sequences? I think that is one reason to
> leave it
> as a procedure or function.
With the same logic, why should the find() function exist? It only iterates
the top level of a sequence, yet it's very useful and your code can get much
faster if you structure your sequences so you can use it.
Regards, Alexander Toresson
6. Re: case and foreach
- Posted by Greg Haberek <ghaberek at gmail.com>
Mar 31, 2005
-
Last edited Apr 01, 2005
> I've thought about foreach and I don't really think that it needs to be added
> to the language because it can be done with a function or procedure.
> One problem with a built-in foreach -- does it only iterate the top level of a
> sequence or does it dig down through sub sequences? I think that is one reason
> to leave it as a procedure or function.
What I really need is 'next' because I'm sick and tired of putting a
bunch of code in an 'if' statement.
for x = 1 to 50 do
if some_condition then
-- do a lot of code here
end if
end for
-- OR --
for x = 1 to 50 do
if not some_condition then
-- skip to next x
next
end if
-- do a lot of code here (1-level down)
end for
'select/case' would be nice, too. :)
~Greg
7. Re: case and foreach
- Posted by codepilot Gmail Account <codepilot at gmail.com>
Mar 31, 2005
-
Last edited Apr 01, 2005
I think the modified "for x in s do" is just about perfect.
But what about selectively not doing the iteration on some elements,
like every even one.
for x in s do-all
end for
for i = 1 to length(seq) by 2 do--odd
x=seq[i]
end for
for i = 2 to length(seq) by 2 do--even
x=seq[i]
end for
for x in s by 2 do--odd
end for
for x=2 in s by 2 do--even
constant bitmap={1,0,1,0,1,0,1,0}
for x in s by bitmap do--any arbitrary bitmap same length as s
end for
--same as
for i = 1 to length(s) do
if not bitmap[i] then next end if
x=s[i]
end for
--but since there is not next
for i = 1 to length(s) do
if bitmap[i] then
x=s[i]
..............
.............
..........
end if
end for
Lets try this example and see the optimization
sequence a,b
a=rand(repeat(128,256))-1--256 seq all bytes
b=rand(repeat(128,256))-1--256 seq all bytes--
for i = 1 to length(a) do
a[i]+=b[i]
end for--normal method
for x in a and y in b do
x+=y
end for--new method
--new method can allow for sse2 optimization of 16bytes fit in each,
and if you could hint the code to tell the translator or interpreter
that 'a' and 'b' will all be bytes then it could do the following
mov eax, address of a
mov ebx, address of b
MOVDQA xmm1,[eax]
PADDUSB xmm1, [ebx]
MOVNTDQ [eax], xmm1
in a loop, and if it knew the length of the sequence it could even
unroll it, and make huge speed.
On Thu, 31 Mar 2005 15:03:21 -0800, Alexander Toresson
<guest at rapideuphoria.com> wrote:
>
> posted by: Alexander Toresson <alexander.toresson at gmail.com>
>
> Jason Gade wrote:
> >
> > I've thought about foreach and I don't really think that it needs to be
> > added to the
> > language because it can be done with a function or procedure.
> >
> > foreach(list_of_stuff, routine_id(some_action))
> >
> > or
> >
> > list_of_stuff = foreach(list_of_stuff, routine_id(some_action)) --Prefer
> > pass by reference
> > or optimization of this case
>
> Thing is, this puts the loop and the code inside the loop in different places
> making the code harder to read. Imagine how eu code would be if the for loop
> was implemented the same way, as a function or procedure! Spaghetti-code.
>
> > But it is something that could be helped by having pass by reference and an
> > eval()
> > function.
> >
> > One problem with a built-in foreach -- does it only iterate the top level of
> > a sequence
> > or does it dig down through sub sequences? I think that is one reason to
> > leave it
> > as a procedure or function.
>
> With the same logic, why should the find() function exist? It only iterates
> the top level of a sequence, yet it's very useful and your code can get much
> faster if you structure your sequences so you can use it.
>
> Regards, Alexander Toresson
>
>
>
>
8. Re: case and foreach
cklester wrote:
> Since Euphoria doesn't have objects, I don't see how this would be more
> useful than what's already available.
>
> for each x in 1 to 50 do
> ?x
> end for
>
> Although it would work for iterating through sequences...
>
> sequence s
> s = {1,2,3,4,5}
> for each x in s do
> ?x
> end for
>
> Do any of the OOP libraries out there use this construct to loop through
> objects in a class/library/whatever?
>
Actually, first off, Euphoria does have Objects, just depends on your
point of view of what an Object is. If you step back, and take a look at
Euphoria, as it stands, you'll start to notice, that Objects are actually
Variables, Procedures, and Functions, and classes become the actual
filename. The only thing that remains laxed in Euphoria, is the fact that
Dynamic Includes will not become a possibility, or dynamic creation of
objects at the Language level will happen.
As for your question, yes, SOOP uses the for method mentioned in the second
half to manipulate the Variable Table, by implementing the DataType System.
It actually becomes:
for x = 1 to length(ObjectMembers[ix]) do
ObjectMembers[ix][x] = DataType_InitVar(soop_MemberType(class_ix,x))
end for
Personally, I like the foreach system, but I'd rather prefer it as a
builtin, so that futher enhancements can happen, such as:
foreach s in x as y do
printf(1,"%s is %s",{y,s})
end foreach
Where y becomes a refrence Identifier, or in the lack of refrence identifiers
in euphoria, the numeric subscript of the item.
As for the top level sequence, or scan through sub-sequences, it should be
fairly ovious, that it should only deal with the top level sequence. Any
sub-sequencing that needs to be done, should be included as a new
foreach statement block. Such as:
sequence x
x = {1,{2,3,4},5,{6}}
foreach s in x as y do
if sequence(s) then
foreach z in s as d do
printf(1,"%d:%d Value: %d",{y,d,z})
end foreach
else
printf(1,"%d Value: %d",{y,s})
end if
end foreach
Just my thoughts on it. As for the case deal, yes, this would indeed
clean up the if/elsif/elsif/elsif/end if block, where you could have about
half a million cases to a simple if switch. However, it's more likely that
you'll get the foreach, and case implemented either into a Pre-Proccessor,
or into the PD Source, before it'll be seriously looked at, if at all by
Rob. Not trying to be a downer, just pointing that out.
Also, one final note to make, since I've seen this alot.... Some think that
if you use the PD Source Code, to make your own flavor of Euphoria, that your
restricted to Euphoria's "laws" when implementing your features into the
interpreter, since it uses Euphoria's 2.5 engine. However, this is not the
case.
Yes, your Interpreter will be running off the 2.5 engine, for the
interpreter's code space. The application developed under your interpreter,
will be following the rules you layed out in your modified interpreter, not
the 2.5 engine. This means, you can create an entirely new language, and
as long as the code is correct in the source for YOUR interpreter, to follow
the 2.5 engine's laws, then it will work.
Just thought I'd make that remark, cause it seems to be missed.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
9. Re: case and foreach
codepilot Gmail Account wrote:
>
> Pros
> I think foreach could be used to add some parallelism to euphoria and
> simplify a few things that for loops and subscripting are used for.
I can relate some experience here. The D language recently introduced
a 'foreach' construct, and I have been using it where ever I can. It has
made a huge difference by making code more easy to create, read and maintain.
The syntax it uses is (in Euphoria-like code) ...
for each [idx,] elem in seq do
. . .
end for
where the 'elem' is an object whose scope is restricted to the 'for' loop
and the optional 'idx' is an integer that contains the index number for
'elem' - its scope is also the 'for' loop. The code inside the loop uses
'elem' as if it was 'seq[idx]'. You can read 'elem' *and* write to 'elem'.
For example:
for each Line_Cnt, Line in TextFile do
if Line_Cnt = 1 then
doPrintHeading()
end if
if length(Line) != 0 then
if Line[1] = '*' then
Line = "(comment) " & Line[2..$]
end if
end if
PrintLine(LineCnt, Line)
if Line_Cnt = length(TextFile) then
doPrintTrailer()
end if
end for
Altering the length of the source sequence is permitted, but you are just
asking for trouble if you start that sort of thing.
> Case would be good for simplifying if/elsif/else blocks to a more
> manageable level and could also help in optimization.
Of course a 'case' construct would made code more readable and easier to
maintain, but when has *that* ever been a priority. If fact, 'while' and
'for' are for wimps and coding gromets 
> Cons
> Does anyone have something against case or foreach(element in a
> sequence) in euphoria?
Well, it does mean more work for anyone trying to implement the Euphoria
language. So maybe we should all just forget about beating this dead horse;
it ain't ever going to get up.
(Did that come over as a little on the bitter side? Sorry if it did.)
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
10. Re: case and foreach
I too have yearned for the "case", "foreach", and "next" statements. However,
one of Euphoria's goals is to keep the code simple and these suggestions kinda
run against that trend. Regardless, I've found myself wishing I had a "next"
statementmany times when I need to find all possible permutations of a certain
string. Also, if you look at probably 90% of for loops, they seem to be used in
instances where "foreach" would be much better.
"Case" I'm torn on. While yes "select" and "case" would be excellent things to
add you don't really need them. Yes, they'd increase productivity and probably
make it easier to debug but they aren't necessary, "if" and "then" work perfectly
fine (even if it takes longer to type all the conditions in).
"Next" we can live without but most people seem to want "foreach" and
"select/case".
Here's my suggestion for the syntax:
-- select/case
select x do
case 5 then
-- code
end case
case 2 then
--code
end case
end select
-- foreach
foreach o in s by 1 do -- o is an object
-- code
end foreach
11. Re: case and foreach
D. Newhall wrote:
>
> I too have yearned for the "case", "foreach", and "next" statements. However,
> one of
> Euphoria's goals is to keep the code simple and these suggestions kinda run
> against
> that trend. Regardless, I've found myself wishing I had a "next" statementmany
> times
> when I need to find all possible permutations of a certain string. Also, if
> you look
> at probably 90% of for loops, they seem to be used in instances where
> "foreach" would
> be much better.
>
> "Case" I'm torn on. While yes "select" and "case" would be excellent things to
> add
> you don't really need them. Yes, they'd increase productivity and probably
> make it
> easier to debug but they aren't necessary, "if" and "then" work perfectly fine
> (even
> if it takes longer to type all the conditions in).
>
> "Next" we can live without but most people seem to want "foreach" and
> "select/case".
>
> Here's my suggestion for the syntax:
>
> -- select/case
> select x do
> case 5 then
> -- code
> end case
> case 2 then
> --code
> end case
> end select
>
> -- foreach
> foreach o in s by 1 do -- o is an object
> -- code
> end foreach
>
My proposal for SELECT;
select x do
case 0
-- code
case 1 to 4
-- code
case 5 or 7
--code
case 6 or 8 to 9
--code
case else
-- code
end select
I would hope the keywords 'End Case' and 'Then' wouldn't be necessary. (I
think it's cleaner, don't know about you guys?)
Hope the 'or' and 'to' is self-explanatory. Maybe using ',' comma instead
of 'or' might be better, I really don't know. I've also added 'Case Else'
so that 'select' can cope with any values that aren't considered in the
case list.
Derek, you argue that 'select' (among others) runs against the Euphoria
goal to keep it simple, and I disagree that 'select' does exactly that.
I think select is a clean and simple way to determine the content of
a single variable.
Last time I proposed some additions to Euphoria, I got a rather crude
reply - so I'll say this; I love Euphora as it is, I'm just proposing
some of my views of what would make Euphoria more powerful AND simple!
:D
Kenneth/ZNorQ
12. Re: case and foreach
The source code for Euphoria is available
to everyone, so why don't all the users that
are complaining about the lack of case and foreach
simply show everyone how you think it is so easy
to add these features to Euphoria. It is one thing
to wish for and another thing to implement.
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
13. Re: case and foreach
Bernie Ryan wrote:
>
> The source code for Euphoria is available
> to everyone, so why don't all the users that
> are complaining about the lack of case and foreach
Bernie, RobC did make a request for new feature requests, so I don't think
people are complaining here as much as making requests. When RobC doesn't
respond to these requests, then you'll hear the complaining. ;)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
14. Re: case and foreach
Bernie Ryan wrote:
>
> The source code for Euphoria is available
> to everyone, so why don't all the users that
> are complaining about the lack of case and foreach
> simply show everyone how you think it is so easy
> to add these features to Euphoria. It is one thing
> to wish for and another thing to implement.
>
We users cannot implement new features directly into euphoria. However, we can
implement features into the pd source, but without rob agreeing with those
changes, our own modified interpreter will run at least 8.4x slower.
That is too slow for me, and there has to be a miracle before rob accepts the
inclusion of many features requested.
Regards, Alexander Toresson
15. Re: case and foreach
On 31 Mar 2005, at 23:00, D. Newhall wrote:
>
>
> posted by: D. Newhall <derek_newhall at yahoo.com>
>
> I too have yearned for the "case", "foreach", and "next" statements. However,
> one of Euphoria's goals is to keep the code simple and these suggestions kinda
> run against that trend. Regardless, I've found myself wishing I had a "next"
> statementmany times when I need to find all possible permutations of a certain
> string. Also, if you look at probably 90% of for loops, they seem to be used
> in
> instances where "foreach" would be much better.
>
> "Case" I'm torn on. While yes "select" and "case" would be excellent things to
> add you don't really need them. Yes, they'd increase productivity and probably
> make it easier to debug but they aren't necessary, "if" and "then" work
> perfectly fine (even if it takes longer to type all the conditions in).
>
> "Next" we can live without but most people seem to want "foreach" and
> "select/case".
>
> Here's my suggestion for the syntax:
>
> -- select/case
> select x do
> case 5 then
> -- code
> end case
> case 2 then
> --code
> end case
> end select
>
> -- foreach
> foreach o in s by 1 do -- o is an object
> -- code
> end foreach
This is even cleaner:
function case(object x)
goto x
:1 return("x=1")
:2 return("x=2")
:orangutan return("x needs a banana")
:roo return("as in kanga?")
:{"a","b","c"} return("That is very good, "&nick&"!")
return(type(x))
end
puts(1,case(x))
But alas, that requires a goto statement, and going to something, which
almost every crawling baby can understand, also breaks RDS's message of
"simple".
Kat
16. Re: case and foreach
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Apr 01, 2005
-
Last edited Apr 02, 2005
On Fri, 01 Apr 2005 07:34:01 -0800, Alexander Toresson
<guest at RapidEuphoria.com> wrote:
<snip>
>we can implement features into the pd source, but
<snip>
>our modified interpreter will run at least 8.4x slower.
I think the point is that you must want the improvement enough to
accept such a crippling performance hit, presumably because it cuts so
much time off development.
If you will not (temporarily, see below) then RC is likely to assume
you don't really want the improvement.
If you want improvements, then proof positive that it does not cripple
the performance of, or break, innocent bystanding programs, that do
not use the feature, can only benefit your argument for them.
>That is too slow for me,
<snip>
If _you_ are not interested long-term, why should Rob be?
I think Rob has made a very bold move in releasing the open source
eu.exw. He has not (afair) said so much but it can only be to solicit
sensible improvements. Simpler, better, well-tested mods may well
encourage him to release 2.6 sooner rather than later. No useable mods
at all & I guarantee we'll wait as long as the 2.4 to 2.5 release.
Regards,
Pete
PS my offer of being kicked into keeping
http://palacebuilders.pwp.blueyonder.co.uk/pdeuex.htm
up-to-date is still valid, not that I have touched it in 2005 ;-((
