1. Re: 3.0 feature request: foreach
Vincent wrote:
>
> 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"
> >
>
> Hi there... 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.
> It could perhaps cause some unnecessary comfusion, when selecting which method
> to use.
> It wouldnt be worth Robert's effort to implement "continue" either, it just
> isn't useful
> enough. Case/Switch could make things more messy too. It's better to use that
> routine_id()
> technique instead, or just plain "if" statements. The namespace proposal would
> add
> extra complexity to the already comfusing scope rules, and could cause a few
> more subtle
> bugs to occur. 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.
>
> Using UPX for EX.EXE and hardware floating point compiler flags, background
> transparent
> icons, and a nice multitasking library & documentation dirived from Language
> War's
> Sched.e would make the nice addition for Euphoria 3.0.
>
> I'm looking forward to 3.0, I can't wait to try out the "Language War"
> technique, seeing
> how much smaller EX.EXE is, and observe those new Windows icons on my colorful
> desktop
> backgrounds.
>
>
> Regards,
> Vincent
>
> ----------------------------------------------
> ___ __________ ___
> /__/\ /__________\ |\ _\
> \::\'\ //::::::::::\\ |'|::|
> \::\'\ //:::_::::_:::\\ |'|::|
> \::\'\ //::/ |::| \::\\ |'|::|
> \::\'\ //::/ |::| \::\\|'|::|
> \::\'\__//::/ |::| \::\|'|::|
> \::\','/::/ |::| \::\\|::|
> \::\_/::/ |::| \::\|::|
> \::,::/ |::| \:::::|
> \___/ |__| \____|
>
> .``.
> ',,'
>
>
Hi there,
My vote goes for Case/Switch, if anything.
There's another argument for case/switch that sets it apart from
other 'nested' type tests, and that is that there is ideally only
*ONE* test performed and then a jump. That single test resolves
into an integer which is then used to determine the jump.
Currently the only way to do this is to make your own case/switch
syntax using routine id's and a whole set of functions.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
