1. Re: each kewword (was: Weird error messages & more)
[Warning: I have re-ordered things a little]
> I disagree. There's nothing wrong with the readability, maintainability,
> etc. of the second example. In fact, the first example could be *horribly*
> confusing, since the loop operation -- instead of being obvious -- is
> "hidden" in that little "each" keyword, lurking way out there on the end.
Why would you want to see it as a loop operation ? Aren't such operations hidden
everywhere ?
What if, printf accepted sequences as value-arguments, in such way it would do
the same ?
[an example how to use the 'each' keyword to simulate get_bytes in only one
statement]
> In Euphoria 2.1, you can include get.e and code this:
>
> s = get_bytes(fhandle, 10)
>
> Which is much cleaner than either of the above examples.
In which way is the loop operation obvious now ?
Also, don't you think it is interesting such a *routine* is (and had to be)
added to Euphoria Langage ? (thankfully though, now
just hope Robert optimizes making it fast built-in function that uses blocks
directly from the buffer)
> [Not to mention the serious logistical problems the interpreter would have
> to face, trying to figure out where the programmer wants the "each" loop to
> apply to within multiple nested operations. Are you trying to give Rob
> nightmares? :) ]
Its only one statement, in other words, it doesn't really matter, but normal
evaluation order will be fine, for those cases the
chronological order of things matters. (when outputting, rather than storing
values, to be exact.)
> Again, I find example 2 far more "readable" than example 1, since you can
> clearly see what's going on. Yes, you have to type a little more for example
> 2, but the benefits of the obvious loops far outweigh any possible
> disadvantages resulting from the extra typing, IMO.
What benefits ?
Once you get used to it, its a much more readable alternative.
Thats like saying a short term, that you are not used to, is more confusing for
constant use, than using the much longer
explenation is simple words. Compare the following...
'Our main strategy will be foccusing towards better effectivity"
"We will from now on, try to make sure, more than something else, that we are
thinking about how to work faster and cheaper"
Isn't the acceptance of a new term, its effectivity in expression ? Something
clearly applying to 'each'.
> [BTW, the word you're looking for is "equivalent." :) ]
Thanks, equivalent, equivalent, equivalent, equivalent .. (just pushing the
spelling into my head 
> This is far more readable and maintainable than the "each"/"reply" stuff
> would be.
You totally missed the point.
What if I dunno the number of replies I need at the beginning due to the fact it
is influenced / determined by some evaluation
rather than a sequence length. But, this might be my fault as well, since I
forgot to clarify the following.
A function only returns to the reply statement (and keeps its local values)
*during* the statement that is being executed. It is
also quite possible to have two version of one function running each with their
own set of local values.
s = each find ('a',"appel") + each find (' ',"spa cy w orl d t his is, do
nt you th ink")
See ?
> >this way (they would still be backwards compatible), however for
> >those programs that need it they could use a list of all places
> >found, rather that just the first place it is found.
> >
> > Example:
> >
> > sequence s
> > s = "Hello world, what's up ?"
> >
> > printf (1, "A space is found at position: %d", {each find(' ', s)})
>
> You'll get an infinite loop, since "find(' ', s)" will always return 6, the
> position of the first space in s.
Didn't it say " what if find () and match () worked this way ? "
In other words they dont currently. If the reply part together with the each
keyword would be native Euphoria code, the find ()
and match () could be made in such a way. Internally they would work as if they
were a function using the reply keyword.
Currently they don't.
Currently they would not go into an infinite loop either though. Since using
'each' together with a normal function will make it
convert a sequence to a list of values it goes through, or just execute once,
since only one value is returned. In the above
example, assuming like you did, that find () returns a value rather than replies
a value, it would only be executed once.
(unless another each is in the statement)
> It's far more obvious what's going on this way.
No, it looks like a program made for the machine to understand, rather than the
human.
It simple stupid steps, since you can't have the machine effectively combine the
concept of iterations with the concept of data.
> >And like many others, I'm still awaiting the concatonated
> >assignment...
> >
> > { succes_value, return_value } = get (fhandle)
>
> I sort of agree with you here, but what happens if the function returns an
> atom value instead of a sequence? Or a length-3 sequence instead of
> length-2? Type-check failure, I suppose. I agree that this would greatly
> help to simplify some code, and actually might *not* require the Euphoria
> interpreter to be completely rewritten. :)
Internally it would just use a dummy variable, if it wants to..
dummy_s = get (fhandle)
succes_value = dummy_s[1]
return_value = dummy_s[2]
Here as well, a type check error would occur, even though this is native
Euphoria code.
So, even that isn't much of a problem. And like the 'each' keyword, you don't
have to use it, if you don't want to.
(even using libraries that are using it, it in no way forces you to take the new
operator into account)
> P.S. Thanks, by the way, for forcing me to come up with the find_all()
> function! :)
Yes, the 'not' approach is pretty smart, and I'm quite sure will be quite
efficient, it at least won a place in my toolbox.
Ralf N.
ralf_n at email.com
nieuwen at xs4all.nl
Uin: 0389920
