1. Re: each kewword
This is getting interesting...
Ralf Nieuwenhuijsen wrote:
>> >>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?
>
>No, why would you think that ? You were the one that brought up get_bytes ().
>My point is, whenever we make a function, we have a complex task, we wish to
>'shorten' for sake of >maintainability.
>The same task wouldn't be complex at all, using the each keyword.
>
>sequence s
>s = repeat (0, 10)
>each s = getc (fn)
The 'each' keyword makes the most sense in this context. However,
brevity does not automatically translate to easy maintenance. I
don't think shortening the length of the source code to remove
one loop (or a few loops) is worth the loss of readability, even
if 'each' was just restricted to use in assignment statements.
>> 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.
>
>Does it matter if the routine loops or if the end-programmer loops ?
>And why can it lurk in a routine call, but not in a keyword ?
>How much visually obvious is a routine call versus a keyword ? Seriously ?
>And how visually obvious is the workings of the above code fragment and the
>workings of the get_bytes >routine, that counts more
>than 10 lines to achieve the same thing.
The difference between the 'each' keyword and a routine call is
this: I don't have to worry about what goes on when I read a
program and see a routine call. If I see a function, I just
have to know what is returned, and I can mentally continue
reading, with that result in mind. If I see a procedure call, I
can ignore it, unless some global/local variables are altered.
'each' doesn't just return a single value; it acts upon entire
statements, and you have to mentally figure out what's going on
when you read the code. And of course, that fact that it DOES
act upon entire statements is a problem too...
>> -- 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...?
>
> *every* ... *every*
> Just read it like English and it says: "write/put each text_image to each
> file"
> And because of this, order is much less important, than it would be when
> the first image with go to the >first file and the
>second to the second file .. etc. And yes, it has to process them one at a
>time. The whole point, the loop is >now the
>responsibility of Euphoria, and it itself can choose to apply to the loop
>statements either directly after the >call, or
>associate them with the variable-place-holders and have the loop brought back
>to its smallest/most inner >loop. Although, I must
>admit, _this_ would be hard to implement. But even the difficulties of
>implementation do not matter. Do you >think Robert has an
>easy time creating the sequence datatype ? Think not.
!!! Are you suggesting that because Rob already put forth a lot
of hard work into making the Euphoria interpreter, that he
should be willing to put forth just as much to implement a
single new keyword? Hmmm... further on you state that 'each'
could be "easily" implemented by a preprocessor. I believe you
are mistaken. In fact, I would challenge you to begin such a
preprocessor if it's that easy; I think you'll quickly realize
it's not a trivial task.
>> >(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.
>
> Well, considering the fact that Euphoria does its own caching (it does not
> need smartdisk, actually it >surpasses it when
>available) you would expect these routines to take a minimal _extra_ effort and
>code size to the interpreter. I >mean, don't you
>think its silly that for really large files, people have written Int21 wrappers
>to read whole blocks of data from a >file at once
>in half the time Euphoria code could do it, especially considering the fact
>that super-de-luxe-fast caching >routines were
>already 'internally' available ? Why aren't the routines that getc (), gets ()
>and puts () internally use wrapped >?
Your argument works well with reading from a file, but
seriously, it can't be extended to *all* situations. With
the 'each' keyword, that is exactly what would be happening.
>> >>[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.
>
>How can you constantly speak of 'implementation' difficulties, while you have
>no clue how Euphoria is >implemented.
Ralf, anyone who spends time working with the language can
come to several clues as to how it's implemented. For example,
it's clear that routine_id() is executed at run-time, which is
why myself (and others) thought it was odd that it would not
return an id for any given routine. Rob may actually have the
function assign the ids at run-time (instead of assigning each
routine an id at compile-time, and looking it up at run-time),
but we know that routine_id() isn't replaced by a literal value
at compile time. I think Gabriel's "clues" to the working of the
Euphoria interpreter in this case sound pretty reasonable.
>All of the 'each' features, could _easily_ be handled by a preprocessor. In
>other words, in theory, the run->time part of
>Euphoria need not be altered, unless it wants to take advantage of the
>optimizations possible using the >'each' keyword. So, how
>can you speak of complex back-tracking, etc. ? What are you doing with the in
>fact, simple parsing addition >I am suggesting.
>
>A statement is read from left to right. Whenever 'each' occurs, the statement
>is wrapped by a loop, the >variable following the
>keyword is indexed by the loop's-counter. That's it.
>
You're trying to make this proposal sound simple, when it's
not. To implement 'each' like you've suggested would require a
shockingly high number of exceptions and interpreter tricks
(well, at least shocking for the Euphoria community). As an
example, you've already had to clarify that:
puts (each fhandle_list, each text_image)
means *every* with *every*, something a beginner to the
language wouldn't know unless told. And what about:
while (each s = TRUE) do
Here, what exactly is supposed to happen? Yes, YOU may have a
specific interpretation in mind, but that interpretation is
not obvious to anyone else looking at the code. You might just
decide that 'each' is illegal in this situation. Someone else
might come to conclude that it translates into a mess like:
while (s[1] = TRUE) and (s[2] = TRUE) and ... do
which adds more problems; now the 'and's are hidden. And who's
to say that the most logical interpretation isn't:
while (s[1] = TRUE) do
while (s[2] = TRUE) do
while (s[3] = TRUE) do
...
A keyword like 'each' would be associated with many little
details like this that would all need to be fully documented
(and heaven help anyone who forgot one of them.)
>> >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().
>
>What exceptions, what learning curve ? Only because you're too ... (saying this
>would sound rude) does not >mean the concept it
>too difficult, or more difficult. It does not include any exceptions. Its very
>consistent.
>No 'subtle' different ways of working. How dare you criticize my idea, without
>any lack of insight or interest >into what I meant
>?
Personally, I don't think effective expression is the sole
criteria for a single new keyword; otherwise you wind up with
a language like APL. I think simplicity and need should factor
in equally.
But I again agree with Gabriel here; 'each' has little quirks
that would have to be told to every newcomer to the language.
You only need a paragraph to describe how to use 'for'.
Apparently, one needs a thorough outline of material to document
'each'.
>
>> >...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.
>
>There are a total of 2 lies in the above statements.
>1) It would not require major changes throughout the entire
>compiler/interpreter
?!! I would say that it would. Certainly, the changes would not
be trivial.
>2) There are no exceptional conditions involving "each" , so they don't have to
>be taken into account.
Oh? From what I can tell, your proposal allows 'each' to be
used at any time before a sequence (if not, then that's
already an exception). IF that is so, then please tell me
whether or not the following code snippets would all be
handled *indentically*:
- puts (fn, each s)
- puts (fn, {each s})
- while (each s = TRUE) do
- if (each s = each t) then
- s = each myfunction ()
- each s = each myfuntion ()
- each s = each s
- each s = each s * each s
- return each s
- abort (each s)
For each one of the above statements where you have to
explain how it works, "outside of" or "in addition to" the
usual workings of 'each', you have an exception. Shoehorning
a concept from another language into one where it doesn't
quite fit is *exactly* what implementing 'each' would be. It
is indeed a powerful concept, but I don't think it belongs in
Euphoria.
Rod Jackson
