Re: Version 2.4 and beyond
Kat wrote :
> >
> > It is possible to have exec() in the current Euphoria.
>
> 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.
>
> 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.
I don't mean it as separate instance nor thread, just an include file or part of
the
program.
> > 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:
Yes you'd have to keep the list manually.
>
> > 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!
There are thousands of successfull programs written without exec().
Anyway, if you want to create some scripting database or
some other scripting, it would be too dangerous to allow exec()
to do any code / access internal values. You have to
create internal 'playground' for the script, which my solution
provides.
> > 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(),
Well, there are two ways Euphoria can take:
a) fast, multi-purpose, C-like language, but with cleaner data types and syntax,
easy to learn.
b) slow, obscure, yet-another scripting language, with weird syntax, difficult
to learn,
usable only for some scripts like bash, perl, python, awk etc.
I prefer way a). I would even like to see true Euphoria compiler without the
Eu2C step.
(maybe GCC frontend?). You apparently choose way b). Then you should instead of
still
complaining rather bring sequences to mirc.
> 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??
Yes, but it is difficult to write cross-platform libraries because platform A
has an extra
feature other platforms have and platform B lacks feature other platforms have.
Rather
give
users the chance to access full power of the platform via .dll/.so/machine code
and let
them
choose. Visual Basic users even don't know how the API works because they have
an ActiveX
component for everything, and they aren't able to survive without Microsoft.
But I agree the distribution should have basic wrappers - like header files
distributed
with C compilers.
Martin
|
Not Categorized, Please Help
|
|
