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


-----Original Message-----
[mailto:]On Behalf Of Thomas Lindgren
Sent: den 9 mars 2005 15:14
Subject: Re: Parse transformery (Was: Re: Calling internal functions -
foo::bar() ?)

--- Bjorn Gustavsson <> wrote:
> Thomas Lindgren <> 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

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 mailing list