Calling internal functions - foo::bar() ?

[Thomas Lindgren]

--- Kostis Sagonas <kostis@REDACTED> wrote:

> "Thomas Lindgren" <thomasl_erlang@REDACTED> wrote:
>  > ...
>  > Well, the previous optimization only shows there
> is no
>  > real need to forbid :: on grounds of performance.
> 
> Nope, that's NOT what your transformation is
> showing. It only shows
> that you can avoid boxing return values in tuples
> for calls within
> the module and still be able to call the function
> from outside if
> you are willing to pay in code size.
> 
> It does NOT say anything about other types of
> transformations/optimizations
> that you can do for module-local functions (e.g.,
> removing unreachable
> clauses, type tests, profiting from sophisticated
> static analyses, etc).

Fair enough, though I was responding to the
justification at hand.

Note that such a compiler will face precisely the same
situation with a module using export_all. Giving up on
optimization there may or may not be acceptable. (My
own view is, of course, to use module merging,
profile-based optimization, etc.)

As you subsequently mention, a compiler can in
principle generate multiple copies of functions to
take advantage of local optimization opportunities,
including for exported functions. (And indeed, some
compilers do.) Even a compiler using mere inlining
will have the issue that the same original "source
code" can appear in several places in the final code,
optimized for different contexts.

That this sort of optimization may require more
sophisticated debugging support and yield more
difficult compiler bugs than we have today is a
challenge to debugger and compiler implementors, in my
mind, not a reason to forbid that sort of features.
It's not like these problems are insurmountable.

(On the other hand, by all means, do build a
compelling per-module compiler that, e.g., does not
tolerate export_all, and your users/developers may
come to accept that sort of restriction. I for one
certainly wouldn't mind having it around.)

>  > 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 :-)
Well, if a solution can't be found, maybe there is a
reasonable compromise somewhere. 

Best,
Thomas



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