OpenEuphoria

Re: Bind features

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Jun 29, 1999
• 601 views

Ralf Nieuwenhuijsen wrote:
>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)

???

I'm not sure I'm understanding you correctly here, Ralf. Are you saying
a bound program takes up much more space in RAM than the interpreter and
the unbound source would together?

>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.

I've thought about the merits of inlining; especially in cases where
the routine is a function consisting of:

   function x (...)
      return <expression>
   end function

the speed gains might be great (I'm constantly amazed at how relatively
low the overhead is for a routine call in Euphoria.) Of course, there's
still the routine_id problem (except for the local exception you described).

But another problem also comes to mind: error tracing. Pure, clean inlining
would mean that if your routine had an error, it would be very difficult to
track it to your routine. And if you included extra code, identifiers, etc.
to keep track of the fact that an "inlined" routine is being executed, and
what it's name is, you lose much of the advantage of inlining the code to
begin with.

>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)

Well, if I were the one writing Euphoria, I don't think I'd want any of it
to be open source... *especially* parts of the binder, if that's what I
plan on using as an incentive to get people to register. Even making just
the main interface and parser freely available would seem like giving too
much away.

Granted, I'd be interested in examining the code (NOT in modifying it), but
I think the chance of any of us ever doing that is close to nil.


Rod Jackson