foo::bar(...)

[Luke Gorrie]

"Erik.Stenman" <happi@REDACTED> writes:

> 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.)

But people don't trust interpreters to run _exactly_ like the compiled
code (witness recent shell vs. compiler bit syntax differences), so I
don't think this would fly.

> 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.

You could still inline and generate special versions, so long as you
also generated a "fully general" one. Perhaps you could live with that
as a compiler option, similar to debug_info?

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

How about "foo:-)bar(1)" then. :-)

> 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])
> ?

Well, an objection to export_all in general is that it affects how the
program actually runs. In practice this means that when I'm doing
export_all as a compiler switch locally, then I might check in code
that doesn't work when other people compile it normally. I have
exactly this problem when I go to checkin a file but see that I have
an "export_all" in it - to remove it, I have to re-test the module.

I'd much prefer to never use export_all and still be able to do
interactive debugging from the shell.

Cheers,
Luke