Re: registration and requests
Robert Craig <rds at ATTCANADA.NET> wrote:
>> Why there is not something like:
>
>> repeat
>> .
>> .
>> .
>> until x>10 --condition tested at end of loop
>
>Euphoria tries to be a "minimal" language, where
>we avoid adding language features for things that can be handled
>almost as well by existing features.
Hmm...I guess *my* response would be that "repeat...until <condition>"
syntax is rather ugly and not very Euphoric -- it certainly doesn't fit very
well alongside all the while...end while/for...end for syntax. But perhaps
something *like* this would be nice to have:
loop
.
.
.
when x > 10 exit
end loop
1) loop...end loop -- Yes, I know this can be done with "while 1 do ... end
while", but really, that whole "while 1" business looks goofy. And isn't it
a bit slower than a dedicated "loop" would be? Doesn't the interpreter have
to check that "while 1" condition each time through the loop? Not very speed
efficient.
2) when <condition> exit -- The "when" serves the same function as the "if",
except that it specifically indicates the loop's exit condition, and the
interpreter expects it to be delimited with the "exit" keyword. This is a
compact way of showing the loop's exit condition (instead of having to write
out a whole "if" statement just to exit). Best of all, this way you can set
up your exit condition anywhere you want to in the loop -- you're not tied
to having it at the bottom or at the top. Plus, you can maybe even indicate
more than one exit condition per loop this way if you need to.
Many times I've had to write code like this...
-- example "a"
line = gets(fn)
while sequence(line) do
-- whatever...
line = gets(fn)
end while
..which can be a real pain when I forget to include that second "line =
gets(fn)" in my "while" loop. (I've done that WAAAY too many times!)
Euphoria shouldn't encourage that kind of error. With syntax like this...
-- example "b"
loop
line = gets(fn)
when atom(line) exit
-- whatever...
end loop
..that kind of mistake isn't made, and we don't have that extra line of
redundant code.
Yes, yes, I know this "can be handled almost as well" by doing this...
-- example "c"
while 1 do
line = gets(fn)
if atom(line) then
exit
end if
-- whatever...
end while
..but then we're into that useless "while 1" condition again. Man, does
that look weird to waste a "while" on a "1" and use a whole "if" statement
for the loop's exit condition just one line later! And I'm sure it's not
very speedy either.
Oh well. In any case, those are my ideas for Euphoria alternate loop syntax
-- no more "while 1" loops! (NMW1L! -- my new acronymical battle cry :) )
>> seq[..5] and seq[6..]
>
>I've been tempted to add this, but in the first case is it really
>so hard to type a '1'?
>e.g.
> seq[1..5] instead of seq[..5]
>
>The second form would be useful, but I still can't make up
>my mind about it.
I agree that the first form is unnecessary, but the second form is needed,
IMO. Not exactly as depicted above, but rather like this:
seq[6..end]
Where the 'end' keyword stands for 'length(seq)'. I don't see why the 'end'
keyword can't be used here -- after all, the two periods together ('..')
have a special meaning within the brackets, so why not do the same for
'end'?
Using the 'end' keyword like this has another advantage over the seq[6..]
method -- you can do index calculations with it, and use it to indicate an
element instead of a slice:
slice = seq[6..end-1] -- from element 6 thru the second-to-last element
element = seq[end] -- the last element of the sequence
element = seq[end-1] -- second-to-last element of the sequence
(If this looks familiar to some of you, this is the same usage of 'end' that
I originally suggested to Dave Cuny for his Euphoria preprocessor.)
I think this would keep slicing methods consistent with the way they work
now, while eliminating the need to type out 'length(seq)' every time.
Anyway, there's my two cents' worth -- at a penny per idea. What a bargain!
:)
Gabriel Boehme
NMW1L!
|
Not Categorized, Please Help
|
|
