1. Re: each keyword
>(does chip's have a stack or is it a dos/asm thingie ?) But I'm quite sure
Robert meant the stack of local
x86 does provide the programmer with some opcodes (push <reg> and pop
<reg> and something like pushall and popall [they're not called this way,
but I can't remember how they were called]) to deal with stacks. So chip's
do have a stack, but it is most of the time hidden from the programmer in
'higher' programming-languages.
>I mean, something like get_bytes is the first thing you would want to see
optimized since 99% of all programs have a choice of
>effectively use it.
>(together with a load_file, load_bfile and load_textfile in file.e the I/O
interface for _most_ programs would be very easy)
>
>No, IMHO, things like 'mouse'-support and other OS-related stuff can be
left out. (graphics, for example, there are much better
>libraries) or at least provided through libraries rather than 'built-in' ..
and trust me.. those are the size penalty, not a
>built-in get_bytes ()
I agree (I have to admit I didn't know WHAT routines we were talking about,
now I know: I/O-routines).
>> >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
>
>It seems everybody dislikes the short form, although it too, offers 'some'
examples, I would already be _extremely_ pleased with
>the introduction of David's syntax. Esspecially, but most likely not, when
it would also supports 'functions', in the way I've
>shown.
Well I don't dislike the short form, it can be quit useful. But when you
want to keep Euphoria simple (as Craig says in his docs) I don't think you
should add a quite powerful, but difficult short form of the
'each'-statement.
>> 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]
>
>Hmm, oops. I guess the latest result would in theory be the likely result,
although not the disered one, I admit.
YYEESSSS... Got you :)
>> >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...
>
>No it does not. Try print (1, {1,2,3} * {1,2,3})
>Euphoria, as an exception, or to be consistent (choose), will do the
following, because the two sequence are of the same length.
>
>{1, 4, 9}
>
>But what when they are not of the same length ?
Damned... Now you got me :(
Bye,
Martin Schut
