Parse transformery (Was: Re: Calling internal functions - foo::bar() ?)

[Ulf Wiger (AL/EAB)]

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/