1. Re: EXECUTE and "Procedural Parameters"
banjo <banjo at SQUIZ.CO.NZ> writes...
::>> 3. A procedural parameter capability - you could write highly
::>> generic routines without needing to redefine
::>> procedures or functions for (for example)
::>> comparisons. "function sort(fooseq, compareproc) ...
::>> if execute(compareproc) = -1 then ..."
E::> I don't understand this one.
Consider the following meaningless example: Fooglish, an alien
language, is for all intents and purposes identical to English,
except that Z is the first letter of the alphabet (before A)
instead of the last. To alphabetize something in Fooglish
alphabetical order, you would need a compare function that took
the difference into account:
usercompare = "if leftparam[1] = 'Z' then\n return -1\n else\n return co
mpare(leftparam, rightparam)"
procedure xsort(sequence tobesorted, sequence compareproc)
...
if execute(compareproc) = ...
...
end procedure
xsort(fooglishwords, usercompare)
The variable usercompare contains the code that defines the
change to Fooglish; xsort is a procedure that is designed to
take a procedure as one of its parameters. When we call xsort,
we pass as one of those procedures the text of the procedure we
wish to use, in this case stored in the variable usercompare.
If you are familiar with C, this sort of thing is frequently
done with pointers to functions being passed to other
procedures, for data-driven selection of functions to use in a
particular context. The difference here is that the procedure
can be defined at run-time, rather than having to be
predefined.
E::>>
::>> 4. A dynamic code facility - since "includes" are idempotent,
::>> and cannot be done except at the absolute top level
::>> of the program, there's no simple way of defining
::>> what gets done "on the fly" such that you can have
::>> the Euphoria-knowledgeable user instruct you as to
::>> how to handle unforseen situations, and be able to
::>> implement those solutions immediately (i.e., without
::>> shutting down and restarting the program).
::>> "while 1 do ... userproc = ... execute(userproc) ..."
E::> This is exactly what i want.
::> Especially if the imported procedures could be stored in a precompiled
::> form, with necessary stubs to slot right in, fast...
::> and of course could recieve paramters and return.
Inherent in the model.
E::> And if they could call imported procedures, then you'd need some method
::> to avoid infinte regression and overflowing the stack, etc.
::> I'd favour a system variable that let you set the size of the stack, and
::> whether the overflow would exit the program or be a 'soft error' that ende
d
::> the function, returning a NULL or somesuch.
You wouldn't need this any more than you do now.
E::> I'd like to know more how the interpreter works, does it create
::> bytecode ?? Can that bytecode be loaded on the fly.
Yes, it does - this is in fact what happens when you shroud a
program or library include file, and then execute it with the
same EX.EXE that you use for unshrouded programs. Under the
EXECUTE proposal, it could be loaded on-the-fly, just as
cleartext (source) could.
=========================================================================
Jeff Zeitlin jeff.zeitlin at execnet.com
---
~ OLXWin 1.00b ~ Mary had a little lamb. The doctor was surprised.
