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

[Thomas Lindgren]

--- "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
wrote:
> 
> 
> 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.


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

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

Well, I'd classify the above as falling under your
second alternative (fall back to
unoptimized/deoptimized/... code for debugging), and
what I wrote was really about the first one (provide
an extra debug wrapper that actually exports all
functions). 

Your second alternative sounds fine to me, keeping in
mind the previous caveat that code loading will have
to change to avoid nasty surprises. (Also, as Vlad
points out, assuming that the debugging does not
concern compiler bugs :-)

The alternative of having a per-module compiler that
doesn't do much when export_all is used is also fine
by me, as mentioned before. It can still be a useful
tool, when applicable.

Best,
Thomas



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/