OpenEuphoria

Re: 3.0 feature request: foreach

• Posted by Derek Parnell <ddparnell at bigpond.com> Jul 13, 2005
• 450 views

Michael Nelson wrote:
> 
> 
> Derek Parnell wrote:
> 
> >
> >posted by: Derek Parnell <ddparnell at bigpond.com>
> >
> >Vincent wrote:
> >
> >[snipped: A lovely little apologia for RDS that celebrated the status quo]
> >
> >By the way Vincent, is your other name "Robert Craig" by any chance ?
> >
> >  
> Derek,
> 
> Your sarcasm detector must be on the fritz. Vincent has been highly 
> critcal of the stutus quo.

Fair call. 

I'm having a shitty week, politely developing a project plan with a client 

However, what I don't yet understand is why is Vincent so strongly arguing for
the status quo with regards to ...

> I don't think there needs to be any more loop methods. "while" and "for"
> are good enough. Foreach would introduce the "in" identifer, and the
> "foreach" keyword." 

All I can add is that for those languages that have a foreach construct, the
clarity of code is enhanced when compared to alternative constructs.

> It could perhaps cause some unnecessary comfusion, when selecting which
> method to use.

Huh?  If a coder is going to be confused between "for i = 1 to length(x) do" and
"foreach e in x" then what are they doing coding? Either they stick to what they
know or they grow by learning.

> It wouldnt be worth Robert's effort to implement "continue" either, 
> it just isn't useful enough. 

And how was the "usefulness" value determined? I have many instances in which my
Eu code can be clarified by this idiom. If "exit" was deemed useful then so would
"next" or "continue", especially once people start seeing the freedom of
expression and clarity is gives to coders.

> Case/Switch could make things more messy too. It's better to use
> that routine_id() technique instead, or just plain "if" statements.

Again, the status quo de-emphasises clarity of code. Sometimes a set of "if"
constructs can be more obscure that a "switch" construct.

   if fld = 1 then
     . . .
   elsif fld = 3 then
     . . .
   else fld = 6 then
     . . .
   end if

or

   switch fld
     case 1
        . . .
        end case
     case 3
        . . .
        end case
     case 6
        . . .
        end case
   end switch

> The namespace proposal would add extra complexity to the already comfusing
> scope rules, and could cause a few more subtle bugs to occur. 

True, some proposals will be more confusing. The only one I see as being useful
is the one that limits global name lookups to the tree that is directly involved.

Currently, if B includes A, and D includes C, then when E includes both B and D,
and if the same name occurs in both A and C, then either B or D will report an
error. They do because now B also looks into C even though it never includes it.
This error doesn't make sense and causes problems for independant library
writers.

>Thread safety would be alot of work on Robert's part to implement, and
> probably only a small percentage of programs would take advantage of it.

Agreed, if we are talking about using the native operating system threads.
However, the concept of threads (ala LangWars) is very useful for many
applications. If there was some built in support for it either in the language or
as a library, then it would help people having to continuously 'reinvent the
wheel'. Though what generally happens is that they don't bother and a poorer
application is developed instead.

-- 
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria