Parse transformery (Was: Re: Calling internal functions - foo::bar() ?)
Ulf Wiger (AL/EAB)
ulf.wiger@REDACTED
Wed Mar 9 15:23:11 CET 2005
Still, such a workaround, if it can be applied conveniently
in the field (which may be difficult if the requirement is
"no source code available"), would satisfy those backward
people who favour debuggability over speed. ;-)
That is, if by a simple command, one can convert a module
from "normal mode" to having all local functions reachable,
I would think that most people would be happy. Those who
care more about debugging than speed at the time, will
happily pay the performance price. Nobody else will
have to.
/Uffe
-----Original Message-----
From: owner-erlang-questions@REDACTED
[mailto:owner-erlang-questions@REDACTED]On Behalf Of Thomas Lindgren
Sent: den 9 mars 2005 15:14
To: erlang-questions@REDACTED
Subject: Re: Parse transformery (Was: Re: Calling internal functions -
foo::bar() ?)
--- Bjorn Gustavsson <bjorn@REDACTED> wrote:
> Thomas Lindgren <thomasl_erlang@REDACTED> writes:
>
> > Alas, for optimization purposes it's the moral
> > equivalent of exporting the function. The
> transform
> > introduces an unknown caller to all functions; if
> the
> > compiler does not account for this, certain
> > optimizations will be unsafe.
>
> Since the wrapper function presumably is exported,
> the optimizer will not generate unsafe code, but
> will simply do less optimization.
Sure, so it's "the moral equivalent of exporting the
function".
Given a debug wrapper exporting all functions (even
indirectly, as in the parse transform example), a
conscientous compiler is obviously back at the
export_all level of optimization. Ignoring the
wrapper, on the other hand, leads to unsafe
optimization as described previously.
There may be ways around this dilemma, of course.
Best,
Thomas
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
More information about the erlang-questions
mailing list