Re: each keyword
>> -- 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.
>
>Off course not. What 'loop' statement would be inserted before the printf
()
>statement in the execution stack. When it
I don't know that much about compilers, however when I look now to
Euphoria-keywords it looks to me they can all be processed in the order they
are in the program. The way you want to implement the "each" statement you
can't always step forward through the programming (at compiling time), you
will have to step back to insert the loop-condition. When the compiler is
set up to work in this way (just add the statements to the end of a list),
then adding the "each" keyword can be a problem. But enough about this,
since as said we don't know how the compiler work.
By the way: I don't know where you came up with "execution stack" but if it
is stated this way in the Euphoria documentation it should give you a clue.
Stacks do only support to push items on the stack (at the top) and pop only
the last pushed item from the stack. You sure don't have the possibility to
INSERT an item, you have to use (linked) lists for this. But I don't think
Euphoria has a stack anyway.
>> >(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.
Your right you can't add *every* routine, however some keywords are quite
important and thus should be optimized and included in the Euphoria core. I
agree with you to not include to much routines. I don't think people who
want to make .exe would appreciate that much, since .exe-programs consist of
the Euphoria interpreter with the source code concatenated ( *** please
correct if I'm wrong, I just guessed this is the way it works ***) By adding
to much functions to the Euphoria core you will increase the size of the
.exe-files which are now small, which is a big advantage for commercial
developers. At least I like the small Euphoria .exe's more then those
oversized VB-applications with its runtime libraries.
>> s = find_all(' ', string)
>> with each pos in s do
>> printf(1, "Found a space at %d\n", pos)
>> end with
This is implementable into the compiler (I think), readable and
understandable for the programmer. And it looks better then a
"length(s)"-statement.
>> >Isn't the acceptance of a new term, its effectively 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().
I agree here, each-statements can be very powerfull, however they do
increase the learning curve. And yes I know I don't have to use it. But when
you start learning a new language you will (well at least I do) look at the
code of other programmers and when they use the 'difficult' each keyword it
will increase the learning curve, whether you're going to use it or not.
>> >...And like the 'each' keyword, you don't have to use it, if you don't
want
>> to.
See above.
>How dare you criticize my idea, without any lack of insight or interest
into
>what I meant?
Maybe you should explain the whole idea better. I think a initially simple
idea will become a better idea when someone criticize it. Because of the
criticism you have to think about it and it will become a better idea.
>The each keyword means: rerun the statement using every element of the
following variable.
>puts (1, "The tables of three are:\n")
>s = {1,2,3}
>print (1, each s * each s)
>
>Using David's syntax you would have written it like:
>
> puts (1, "The tables of three are:")
> s = {1,2,3}
> for each itemA in s do
> for each itemB in s do
> print (1, itemA * itemB)
> end for
> end for
>
>I am personally in favor of having 'both' syntaxes.
3 reasons why I should use David's syntax:
- It is easier to implement in a preprocessor (or Euphoria)
- It is clearer what it does. each {1,2,3} * each {1,2,3} could accidentally
be read as {1*1,2*2,3*3}, with David's syntax it is very difficult to read
it his way :)
- As you stated yourself it is more flexible
>About the assignment operator...
>In the above the number of iterations of the statement is obvious: 3 * 3.
>But what if the statement read:
>
>each z = each s * each s
>
>Well, in this case its not:
>length(z) * length(s) * length(s)
>
>With assignments, the left-side determines the amount of iterations, but
stops if the right side is unable to deliver new
>values.
>
>sequence s, z, g
>s = {1,2,3}
>z = {4,5,6}
>g = repeat (0, 27)
>
>each g = each s * each z
>-- only the first 9 elements of g are set.
Yes, but what about something like
each s = each s * each s
OK when this is can't be done this can:
s = {1,2,3,4,0,0,0,0,0}
each s = each s[1..3] * each s[2..4]
Won't s change immediately and update its values after it has executed all
loops, giving this:
s = {2,4,6,3,6,9,4,8,12}
Or will it update immediately and give this as a result:
s = {2,4,6,4,0,0,0,0,0} -- each s[1..3] * s[2]
s = {2,4,6,12,24,36,0,0,0} -- each s[1..3] * each s[2..3]
s = {2,4,6,12,24,36,24,48,72} -- each s[1..3] * each s[2..4]
>A thing that would complement 'each' a lot would be 'all' though.
>
>s = {1,2,3}
>print (1, all s * all s)
>-- displays:
> -- 1
> -- 4
> -- 9
Sorry to say this but a simple print(1, {1,2,3} * {1,2,3}) does exactly
this...
Bye,
Martin Schut
P.S. Don't know whether it is the weather or something but it seems that on
all mailinglist there are arguments going on. For now mail coming from the
Euphoria-mailserver with in the subject 'saving and reading sequences' is
redirected to /dev/null just as all mail with as subject 'SPAM' or mail that
has been identified as spam in another way. Maybe I should add mail with the
subject 'OFF TOPIC' to my script as well...
|
Not Categorized, Please Help
|
|
