OpenEuphoria

Re: Bind features

• Posted by Lucius Hilley <lhilley at CDC.NET> Jun 29, 1999
• 613 views

Message below SNIPPED but not taken out of context.

I like the idea of an inline feature and I agree with the idea
of Leaving the original routine there for the purpose of routine_id()
calls.  I definately suggest that the inline feature be an option
that can be selected during the binding/shrouding process.

It be an option for the following reason.  If inline is off it
would be easier to detect where the problem arose in the code.

Obviously either the inline should be limited to a number of
statements.  About 10-20 statements should be more than reasonable.
Also there could be an inline trigger so that only certain code
is inlined.  Of course inline would be default set to without.

with inline
function sign(object input)
  return ((input > 0) - (0 > input))
end function
without inline

        Lucius L. Hilley III
          lhilley at cdc.net
+----------+--------------+--------------+
| Hollow   | ICQ: 9638898 | AIM: LLHIII  |
|  Horse   +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+

> ---------------------- Information from the mail
header -----------------------
> Poster:       Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
> Subject:      Re: Bind features
> --------------------------------------------------------------------------
-----
>
> >
> > 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).
>
> Problem ? If its small enough to inline everywhere, you can easily keep
the
> original routine in source code, so routine-id works correctly.
>
> > 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.
>
> You bind you programs when you are developping and debugging them ?
> A lot of programs will crash, when bound, with the 300-statement thingie,
> since bind uses the pd-version of the interpreter, rather than the
> registered version. (logically)
>
> Guess, Robert is less paranoid than you assume.
>
> Ralf
>