Parse transformery (Was: Re: Calling internal functions - foo::bar() ?)
Tue Mar 8 12:22:21 CET 2005
Mats Cronqvist wrote:
> > We agree that export_all is bad. What we disagree on is the relative
> > importance of troubleshooting tools vs. compiler optimization. This is
> > hardly surprising since one of us is troubleshooting running systems
> > all day and the other is developing compiler optimizations. :-)
> i was just going to comment to Kostis that for the AXD301, the choice between
> a 5% compiler optimization and 5% better turnaround time on bug fixes is a
> no-brainer (in favor of better debugging).
What my mail tried to express (and apparently it failed) was that for
a Programming Language Implementation the choice of satisfying the
occasional convenience of *some* users (no matter how important they
are) vs. adding a construct that effectively prohibits optimization
and thus penalizing *all* its user community should also be a no-brainer.
The difference is not that of a compiler writter vs. developer, it is
a matter of quantifying over the user community.
Erlang, as any language, has to have a compilation mode where analysis
or optimizations are allowed. Being able to call arbitrary functions
from anywhere (when the compilation was done without +export_all or
some other option of the form +I_want_to_call_all_functions_from_anywhere)
prohibits not only optimizations, but also reasoning about properties
of the code.
This is my point.
I do not object to the :: construct, I strongly object to it when not
explicitly telling the compiler that you reserve the right to use it.
The default should be compilation *without* the ability to call internal
functions. The opposite is bad not only for my compiler writter wishes,
but also software-engineering wise.
More information about the erlang-questions