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

Thomas Lindgren thomasl_erlang@REDACTED
Wed Mar 9 12:06:48 CET 2005


--- "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
wrote:

> - The parse_transform option that Luke suggested. If
> I understood
>   it correctly, it _doesn't_ export the local
> functions per se, 
>   but rather a wrapper function through which you
> can reach all 
>   local functions. I don't see how this interferes
> much with 
>   the optimization potential.

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.

(In particular, if you call the function from a "sneak
export" unknown to the compiler, you roll the dice and
take your chances. Depending on the optimization in
question, you are likely to get core dumps (type
analysis), corrupt data (reuse analysis), etc.)

> - If debug_info is present, one could do the same
> thing using a 
>   support function that reads the debug_info chunk
> and recompiles
>   it on the fly with export_all, or inserting a
> wrapper function
>   as in Luke's parse_transform.

Some systems support "deoptimization" to enable
debugging; recompiling the code for debugging is
essentially that approach. This seems to work.

The current code manager would have to change to
handle this: first, code purging will be a problem
(loading new modules will eventually kill off
processes that should be alive); second, the existing
call stack will still return to the old, undebuggable
code. Some modification might be needed, thus. 

(A more flexible general scheme for loading and
unloading code might be quite useful for this and
similar purposes.)

I think this might be a useful way forward. One could
see it as "unsealing" and "sealing" the module(s), if
you will, which could replace export_all entirely. 

(Whether everyone will be happy to provide a readable
representation of the source in their shipped systems
is another question :-) E.g.,

http://www.erlang.org/ml-archive/erlang-questions/200101/msg00106.html

(But there might be workarounds to that too.)

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