"Thomas Lindgren" <thomasl_erlang> replied to my post:
> > > Introducing :: may, as you say, still be a bad idea.
> > Indeed it is. A very bad one in fact.
> Given the prevalence of export_all all the way to
> deployed code, there still seems to be a customer, er,
> developer need for this sort of functionality :-)
Just in case some of my points were too implicit, let me make them
Most of us agree that "export_all" is a terrible kludge, but some
feel that is is occasionally helpful in developing/debugging.
However bad it may be, note that at least it has the property that
it allows the compiler to optimize internal functions in modules
that do NOT contain an "export_all". This is something detectable
at compilation time (i.e., when the .beam file is generated) and
trivially also detectable by using "grep".
The BEAM/native code code compiler is thus allowed to say: "Aha, the
programmer has used an export_all in this module; I will punish her
by not performing any optimizations in that module, and will only
optimize the internal functions in the rest of her modules."
The latter is possible _because_ there is currently no construct to
call internal functions.
In the presence of a :: construct, no sophisticated optimizations
are possible to perform without having a fall-back mechanism.
This puts an unnecessarily big implementation effort to the compiler's
optimizer and significantly increases the size of the generated .beam
> Just in case some of my points were too implicit, let me make them
> more explicit:
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 did my thing with a parse transform. My problem now is how to handle
'make' dependencies in the presence of parse transforms. (Anyone know?)
> Kostis Sagonas <kostis> writes:
>>Just in case some of my points were too implicit, let me make them
> 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).
alas, while i personally like the M::F shell-only proposal, i don't see it as
being very helpful in AXD301 development.
a) it's only really useful to the guy who wrote the code...
b) ...and the function is reasonably side-effect free
c) we already have the problem that the shell is abused on live nodes (by
if i thought otherwise i'd be mail-bombing the OTP guys right now.
> The parse transform is lib/msc/src/internal_exports.erl in jungerl.
> P.S. Good luck Mats on getting this adopted for AXD301. :-)
i'll just explain to the bosses that it's object-oriented and they'll give me
a raise :>