1. Dynamic includes
On Tue, Jun 24, 2003 at 06:21:47PM +0000, Al Getz wrote:
<snip matheval stuff>
>
> Hello again Matt,
>
> I didnt mean to imply that your evaluator didnt bind or anything
> like that, i was just stating that mine doesnt bind because
> it uses dynamic includes.
> Would be nice if binding could handle that too 
>
> Take care for now,
> Al
>
For binding, dynamic includes are not impossible. I am not sure, but it would
not be difficult for the interpreter to add support for include when in binded
mode. The "include filename" part would have to be cleartext in the binded file
tho.
Obviously, this won't work for a translated program (short of putting
the interpreter into the translated program ... but the overhead for that
is clearly not worth it).
Another approach is this (example using dynamic includes depending on
platforms):
Run the file on the platform you intend to bind, but set it up so that the
files created dynamicly are NOT deleted. (I.e. use 'set_delete_dynamic(0)'
or something.)
Then after it is run, set up the program code to not write out the dynamic
files (i.e. use 'do_write_dynamic(0)' or somesuch) and then bind it.
Repeat for each platform you intend to bind for. This sort of thing is
tedious but doable, and it is also a usable method for the translator as well.
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
2. Re: Dynamic includes
Matt Lewis wrote:
> Well, I only saw one reference (in a rather quick search of the mailing list
> archives) that was derogatory toward executing strings (besides Rob, of
> course). I've thought it would be a good thing to have, and have even
> applied some thought as to putting it into the Euphoria source code, but I
> always get lost in the scanning/parsing routines.
Well it would be easier to implement in an interpreter than in a compiled
version!
It is a very different animal to Euphoria, but it might be worth looking
at what NoteTab does. It substitutes variable names by their values into
the "source line" and then rescans and does the same again as often as
required. This does allow some very clever stuff to be done and I for one
would like to have some such facility.
But making a compiled version of that is rather trickier as I said because
usually the variable names are gone by then, but in this case they could
not be.
Is there already a general facility in Euphoria to access a variable from
having its name in a string? This is a useful capability to have. There
is one Euphoria command/proc/function that has the variable name as a
parameter in quotes - I forget which one.
3. Re: Dynamic includes
> Is there already a general facility in Euphoria to access a variable from
> having its name in a string? This is a useful capability to have. There
> is one Euphoria command/proc/function that has the variable name as a
> parameter in quotes - I forget which one.
<snip>
routine_id
Syntax: i = routine_id(st)
Description: Return an integer id number, known as a routine id, for a
user-defined Euphoria procedure or function. The name of the procedure or
function is given by the string sequence st. -1 is returned if the named
routine can't be found.
2Comments: The id number can be passed to call_proc() or call_func(),
to indirectly call the routine named by st.
The routine named by st must be visible, i.e. callable, at the place
where routine_id() is used to get the id number. Indirect calls to the
routine can appear earlier in the program than the definition of the
routine, but the id number can only be obtained in code that comes after the
definition of the routine - see example 2 below.
Once obtained, a valid routine id can be used at any place in the
program to call a routine indirectly via call_proc()/call_func().
Some typical uses of routine_id() are:
1. Calling a routine that is defined later in a program.
2. Creating a subroutine that takes another routine as a parameter.
(See Example 2 below)
3. Using a sequence of routine id's to make a case (switch) statement.
4. Setting up an Object-Oriented system.
5. Getting a routine id so you can pass it to call_back(). (See
platform.doc)
Note that C routines, callable by Euphoria, also have routine id's.
See define_c_proc() and define_c_func().
the debate over whether or not Euphoria should include a function called
variable_id() has gone on for some time. i believe someone altered the
interpreter to incorporate this, and it lies somewhere in the archive. i for
one would like it, and have found a need for it on occation.
~Greg
g.haberek at comcast.net
4. Re: Dynamic includes
Greg Haberek wrote:
> the debate over whether or not Euphoria should include a function called
> variable_id() has gone on for some time. i believe someone altered the
> interpreter to incorporate this, and it lies somewhere in the archive. i for
> one would like it, and have found a need for it on occation.
Yes Greg, that is what I was really asking about.
Thanks
Ray
5. Re: Dynamic includes
> From: gertie at visionsix.com
> Subject: RE: Dynamic includes
>
>
> On 25 Jun 2003, at 15:39, Al Getz wrote:
>
>
>>jbrown105 at speedymail.org wrote:
>>
>>>
>>>On Tue, Jun 24, 2003 at 06:21:47PM +0000, Al Getz wrote:
>>><snip matheval stuff>
>>>
[big snip]
>
> I'd still go with executing strings. You could then gets() the "include" file
> you
> want, parse each function to a subslice, and then execute them as if they
> were a routine_id. (Hmmmmm,, makes a good point for pointers to vars.)
> Visability of variables and other procedure/functions would be whatever is
> visable at the point the line is executed in the program, making it
> interesting
> what's "namespaced" or visable at different execution points. Alternatively,
> the subseq containing the function could have the vars prepended to it as
> you wish at any time. You could possibly call a function to set up the string
> "include", using vars scoped at the point of the function you called, and
> execute the string with that scope somewhere else in the program. This
> would be rather like the pascal with..do block.
>
> But people have already said they do not want self-modifying code or string
> execution. <sigh> It's useful in mirc, people, and it would be useful in Eu
> too,
> making Eu more useable to me.
>
> Kat
>
Agreed. Actually, dynamic includes could solve any situation where Eu
processes interact between one another and with some form of outer world
(user responses or anything like this). I would definitely support this.
Note that OE will probably implement a limited form of this by spawning
a new process to execute the dynamic string in an independent scope.
Arbitrary string execution could be tricky.
Dynamic includes are NOT self-modifying code. They are code with
instruction flow self-control.
CChris
>
