OpenEuphoria

Use of include and/or eval and/or dynamic code executaion WAS:

• Posted by Andy Cranston <andy_cranston at LWSYS.FSNET.CO.UK> Feb 02, 2001
• 482 views

Hi All,

I've been following the threads on include usage, an ability for "eval"
type capability and dynamic code execution with interest.

For my *possibly* negative 2 cents/pennies worth here is my take:

===Includes===

I'm taking the Euphoria include to be the same as the #include of C.  To my
mind the whole include mechanism is for platform independence and inclusion
of standard libaries.  In effect you "include" a file once and once only.
Infact a look at an include file in a UNIX system shows things like this:

#ifndef __STDIO_INCLUDE
#define __STDIO_INCLUDE
.. all the stdio.h stuff
..
..
#end if

so if this particular include file is included a second (or more) time the
effect is silently ignored.

===Eval===

The eval function can dig you out a whole.  On UNIX eval is a command in
it's own right callable from any UNIX shell (a UNIX shell is just a program
that runs a shell script program in the logically same way that Euphoria
runs a Euphoria program).  As I say it can be a life saver but IMHO I like
to see it's use restricted to only when necessary but then YMMV.

===dynamic code execution===

If this is the availabilty of an "eval" function inside Euphoria then I
would not object.  What I *would* object to is Euphoria code that has
*lots* of eval statements which are not clearly commented/documented.  An
eval function gives you the ability to write programs that modify
themselves during runtime.  While self modifying programs open up "new
horizons" (perhaps in AI? - I'm no expert) I've always found a self
modifying program harder to debug than one which leaves itself alone.

YMMV but if you go the self modifying program route then I'd strongly
advise you to get some good runtime debugging tools because when the code
"errors out" your not debugging the program source but instead you are more
than likely debugging a modified version of the source that may or may not
reside in memory or some special files.  Sounds fun.

Anyway maybe I'm from the old school but "don't write self modifying code"
was the mantra in my early days.  I can learn new spots though - I'm open
for persuasion.  It's what the list is all about.

Regards,

Andy Cranston.