1. Re: each keyword
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Apr 22, 1999
-
Last edited Apr 23, 1999
> 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.
Robert once said at all places stacks were used, he used his own stack code,
which was more dependable than the chip-stack.
(does chip's have a stack or is it a dos/asm thingie ?) But I'm quite sure
Robert meant the stack of local routine variables
rather than the program. Oh well.
> >> >(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.
Yes, well seriously, I agree here, but minimizing the routine and keywords base
can be best done, by chosing the right routines
and keywords. Rather than getc () being built-in, and get_bytes () using getc ()
in a routine, I would want to see it
visa-versa.
The getc routine would then be:
global function getc (integer fh)
sequence s
s = get_bytes (fh, 1)
return s[1]
end function
The gets routine would then be:
global function gets (integer fh)
sequence ret
integer char
char =getc (fh)
while char != -1 and char != '\n' do
ret = append(ret, char)
char = getc (fh)
end while
if char = '\n' then
return append(ret, '\n')
else
return ret
end if
end function
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 ()
> >> 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.
Yes, David Cuny came up with this a long time ago. He has a preproccesor that
works with his TextGUI editor (EE) that offers
this as well as other things.
> >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.
True, I had not considered to 'enable' or 'how' the interpreter would handle the
'each' keyword when applied in a comparisation
of any kind.
But l must say, there already is (short-circuit) a difference in how the
interpreter handles such things seeing them as
'mathimatical' comparisations or logical comparisations. The logical ones
(requiring a TRUE/FALSE value are short-circuited in
_some_ cases, not _all_ .. btw why not in return statements of trace routines ?)
In mathimatical context I have already explained how it works.
In logical context, I wonder how and if it should be handled.
> >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.
> 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.
> >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 ?
print (1, {1,2,3} * {1,2,3,4})
{{1,2,3,4}, {2,4,6,8}, {3,6,9,12}}
..or ..
{{1,2,3},{2,4,6},{3,6,9},{4,8,12}}
.. I can't remember...
> 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...
The weather.. hmm, I wonder how much influence it can have on our moods ..
I'm quite sure, though, that humans do not make choices as rational as you tend
to want to belief they do.
(I myself, can often catch myself, on find a rational answer, while I already
made up my mind, but then again, i'm supposed to
have this whole hormones mess inside of me.. so who knows ?)
Ralf
