foo::bar(...)

[Erik.Stenman]

It looks like a nice feature but I object to letting anyone call exported functions.
(If the shell was rewritten to interpret erlang source code then it could be permissible to allow calls to unexported functions, but not to functions in a beam file.)

The reason is that it would make some compiler optimizations impossible. As it is today, inlining might remove a non-exported function completely, and in the future the calling convention for non-exported functions might be changed so that functions returning tuples instead returns multiple values.

Also the token :: is "reserved  by HiPE" for parametrisized modules ;)

If putting the export_all option in the file is to cumbersome for you why don't you just supply it as an argument to the compiler:
c(foo,[export_all])
?

/Erik
--------------------------------------
I'm Happi, you should be happy.
Praeterea censeo "0xCA" scribere Erlang posse.

 
----- Original Message ----- 
From: "Luke Gorrie" <luke@REDACTED>
To: <erlang-questions@REDACTED>
Sent: Thursday, September 26, 2002 3:00 PM
Subject: foo::bar(...)


> Hi all,
> 
> I suggest that Erlang be extended to allow calling unexported
> functions. This could be restricted to the shell to avoid any
> software-engineering objections. The syntax could be "::", like:
> 
>   foo::bar(1)
> 
> This would let you use the shell to test logically module-internal
> functions without having to toggle "-compile(export_all)" all the
> time. Sensible people get annoyed when I checkin export_all's to CVS,
> and I get annoyed when I need to toggle it on/off between checkins
> while actively hacking/testing modules. This seems like a nice
> balance?
> 
> The idea is borrowed from Common Lisp.
> 
> Cheers,
> Luke
> 
>