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

[Kostis Sagonas]

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.

Best,
Kostis