Re: each kewword
Ralf Nieuwenhuijsen wrote:
>[Warning: I have re-ordered things a little]
That's okay, so have I. :)
>>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 ?
??? I don't entirely follow you. The loops are either "hidden" in
pre-existing built-in functions, or within user-written routines. Either
way, they follow Euphoria's existing rules for loops. The "each" keyword
would require those rules to be quite drastically changed -- it would create
loops out of statements that do not normally loop on their own.
>>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 ?
I trust you are not *seriously* suggesting that your "each" idea is in any
way equivalent to a Euphoria function definition?
A pre-defined routine can *obviously* be expected to contain loop
operations. Your "each" loops, again, would create loop operations out of
statements that do *not* normally loop. This has great potential for
confusing the programmer, since the loop is not visually obvious in the
code.
Additionally, in order to create these "each" loops, the Euphoria compiler
would have to "reach back" to code that it has already processed in order to
retroactively create these loops. To illustrate, I will use some of your
original examples:
-- example 1
printf (1, "The next number is %2d", {each s})
When the compiler encounters the "each", it has already processed the
"printf". Now, it has to "reach back" to insert loop instructions before the
"printf" statement. This would certainly slow down the Euphoria compile
step.
-- example 2
puts (each fhandle_list, each text_image)
Same problem as above, only now it has *two* loops it has to retroactively
apply to "puts" (and it has to process them one at a time, too).
Additionally, the statement itself is somewhat ambiguous. Do you want
*every* text image to go to *every* file, or do you want the first text
image to go to the first file, the second text image to go to the second
file...?
>Also, don't you think it is interesting such a *routine* is (and had to
>be) added to Euphoria Langage? [get_bytes()]
It didn't *have* to be included -- other programmers could easily have
written something like it for themselves. It is included for convenience, so
we don't have to re-invent the wheel.
The dilemma Robert faces with the standard include files is to give us all
the library routines we'll need, but not to bloat everything to gargantuan
size with hundreds of additional routines (which may never be used in a
given program). IMHO, he has done pretty well in this regard.
>(thankfully though, now just hope Robert optimizes making it fast
>built-in function that uses blocks directly from the buffer)
You can't turn *every* routine into a built-in just to gain a few percentage
points of speed; otherwise, the bloating problems I mentioned above would
affect EX.EXE and EXW.EXE. Euphoria is pretty darn fast in and of itself.
>>It's far more obvious what's going on [with manually-coded "for" loops].
>
>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.
If you want a good example of "each" being integrated into Euphoria, check
out David Cuny's preprocessor. It employs "with each" loops to achieve (in a
more readable fashion) an effective combination of "the concept of
iterations with the concept of data" (if I correctly understand what that
means).
An example:
s = find_all(' ', string)
with each pos in s do
printf(1, "Found a space at %d\n", pos)
end with
This clearly shows that a loop is taking place, and it doesn't require the
programmer to deal with the sequence indexes. I like *this* a lot better
than a "for" loop. However, this is *quite* a different "each" idea.
>>[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...
?!?!!?!?!!!?!?!!
This shows how little you have really thought through your own idea. This
"one statement" changes *all* the rules Euphoria plays by. Every existing
operation in Euphoria will now have to be able to deal with the "each"
keyword, since your design allows for it to appear just about anywhere. This
is a *major* change to the whole language! To say "it doesn't really matter"
is, charitably speaking, an astoundingly naive statement.
>>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.
Are you suggesting that built-in functions should operate in subtly
different ways depending on whether or not they have an "each" nearby?!?!
Good Lord, what kind of horrific nightmares are you trying to inflict upon
the Euphoria programmers of tomorrow?!
>Isn't the acceptance of a new term, its effectivity in expression ?
>Something clearly applying to 'each'.
Not clear at all. Your "each" idea would clearly steepen the Euphoria
learning curve, introducing whole rafts of exceptions (and exceptions to the
exceptions) into Euphoria's current scheme of things -- just as you yourself
have demonstrated with your ideas regarding find() and match().
>...And like the 'each' keyword, you don't have to use it, if you don't want
to.
Can we *please* stop using this argument for every weird thing people want
to shoehorn into Euphoria? Unlike most major languages, Euphoria is *not* a
hodge-podge of almost-compatible ideas patched very badly together. Rather,
Euphoria has a clear conceptual unity running through almost every part of
it -- which, incidentally, is what helps make it so easy to learn. Adding
this "each" construct to the language would require *major* changes
throughout the entire compiler/interpreter, which could adversely affect
*all* Euphoria code, whether people use "each" or not. Additionally,
learning how Euphoria works could potentially become more difficult, since
exceptional conditions involving "each" must be taken into account.
This is not to discourage you, Ralf, from coming up with new and creative
ideas for Euphoria. Rather, I *encourage* you to clarify your thoughts on
this idea, to clearly show how and where "each" could and could not be used,
and to describe exactly how Euphoria's current behavior would have to
change. The acceptance of a new construct relies on its being clearly
defined, and on taking into account its effects on the programming language
involved. A more clearly defined set of rules for your idea may resolve many
of the issues I have mentioned here.
Be seeing you,
Gabriel Boehme
------
How quickly revolutions grow old; and, worse still, respectable.
G.K. Chesterton
------
|
Not Categorized, Please Help
|
|
