Parse transformery (Was: Re: Calling internal functions - foo::bar() ?)
Ulf Wiger (AL/EAB)
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
[mailto:]On Behalf Of Thomas Lindgren
Sent: den 9 mars 2005 15:14
Subject: Re: Parse transformery (Was: Re: Calling internal functions -
--- Bjorn Gustavsson <> wrote:
> Thomas Lindgren <> writes:
> > Alas, for optimization purposes it's the moral
> > equivalent of exporting the function. The
> > introduces an unknown caller to all functions; if
> > 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
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.
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
More information about the erlang-questions