Re: Version 2.4 and beyond
On 14 Feb 2002, at 19:27, Martin Stachon wrote:
>
> Kat wrote:
> > And exec(sequence) would
> > allow scripted database entries, as would defining the item as a class while
> > the program is still running. Which would be easier for you Rob,
> > exec(sequence) or build_class(sequence)) ?
>
> It is possible to have exec() in the current Euphoria.
>
> procedure setVarsForExec()
> -- the inconvient part
> -- tells exec() what are values of variables
> setExecVar("foo", foo)
> setExecVar("bar", bar)
> ...
> end procedure
Yeas, i had considered a preprocessor that built var tables, added includes
to handle passing vars back and forth between a second instance of the
interpreter, or sharing the permitted part of the var table with the subordinate
"threads", but it got overly wierd real fast. I didn't see it working.
> procedure setVarsFromExec()
> -- the inconvient part
> -- after exec() variales are updated if they was changed
> -- by code in exec()
> foo = getExecVar("foo")
> bar = getExecVar("bar")
> ...
> end procedure
>
> procedure execCode(sequence t)
> routine => call via routine_id()
> emulate entire euphoria
Well, we can now, with one of several interpreters in the RDS archives. But
routine_id()s are not valid outside the program that they are in. You can't
make a routine_id and pass it to a second program, unless it points to
locked memory, which Rob says to *never* do.
> has its own table of variables
And cannot pass them back. See, you'd need an include in both programs
that knows what vars exist, and their types. You cannot do this in an Eu
script:
set $1 $2
or
//$1
or
if atom(var1) then var1 = $2 end if -- who knows var1 exists?
> end procedure
>
> procedure exec(sequence s)
> t = tokenize(s)
> setVarsForExec()
> for i=1 to length(t)
> execCode(t)
> end for
> setVarsFromExec()
How will you setVarsFromExec() without knowing what vars were already
predefined in the calling code? And their types?
> end procedure
>
> It isn't as fast as exec() built-in into interpreter,
> but allows the code to be translated to C.
Using Eu only as glue language? Cusswords, i wanted a language to write
the whole program in!
> So the only thing that would make exec() easier, is
> the ability to reference variables via their name
> like routine_id() does. But this would introduce
> pointers...
Well, pointers can be hidden from the Eu users, like the items in sequences
are pointers.....
I think we are at the empasse where Rob wants to keep the language as the
ideal he held 12 years ago, rather than make it more broadly attractive and
infinitely useable. It's a given that interpreters are going to be slower than
compiled languages, i accept that. But interpreters can also be smarter. I
draw the line at the language semantically parsing the language syntax like
Rebol, but some new commands, like goto and eval(), and better integration
into the OSs that Eu runs on, such as exw supporting kernal32 disk file calls
transparently to the programmer, are overdue. I once thought Rob might take
a cue from MS integrating things that had been addons (remember
Stacker?), and usurping the original code authors, but now i see the opposite
is happening, Rob isn't adding anything that people are finding universally
useful, it's mostly all in win32lib! I mean !really!, i used seek() in pascal
for
years, in every program, even writing machine code to expand what pascal
provided, and now i can't use it in Eu??
Kat
|
Not Categorized, Please Help
|
|
