OpenEuphoria

Bind features

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Jun 29, 1999
• 670 views

First of all, Rod's problem with 'altering' or 'removing' code because it
effects the program size, can be discarded.
If you want your programs to run on machines with so little memory, why bind
in the first place ? (duh)

Secondly, now I think of it, bind could even do a lot of optimizations, and
inline routines with less that X-number of statements.

Routine-id can cause problems when 'inlining' and 'removing' un-used
routines, however for each file routine-id is not used, all *local* routines
can be removed. All un-used identifers should have issued a warning anyway.
(why not for *all* identifers, during the bind-proccesing, proposing the
simple question:

"Routine my_routine is not used throughout the whole program, do you want it
to remain ? (y/n)"

Also, about the binder/shrouder: for editors and alike, why not keep the
core in a library, shrouded, and the command-line interface as a dos32
program ? (a simple interface that just used the core-library to shroud and
bind program files)

What I would also like (I know, some one else could write as well, but
standarizing *this* makes sence), is a library routine that parses Euphoria
code. You need it for the binder/shrouder anyway. The library could even
offer a simple interpretation routine (not to hard to implement). Yes, off
course it would run slower than when the interpreter executes it itself, but
at least its something. (I don't see Robert implementing dynamic loading of
include files, or even better, 'virtual programs').

And when the parser-code of the binder/shrouder is moved to a standard
Euphoria include, a simple analizing tool can be made fairly easy as well.
Also, why not have *ONLY* the part of the binder/shrouder that encrypts in
encrypted form (together with the tokinzer: just the output-library), while
have the rest remain open source code, so we can add new features to the
binder ourselves, such as excluding certain include files (configuration
files as Eu-includes), incorporation resource-files (David's creation), etc.
We could even add simple optimizers. (for example, for the
xvcxc[23][23][32][423] type of repeated statement: speeding the source code
up by using dummies often complicates the code as well)

Ideas anyone ?

Ralf N.
nieuwen at xs4all.nl
UIN: 9389920

PS. Irv: No france beach for me this year, my own rainy country must do, for
now, anyway.