foo::bar(...)
Luke Gorrie
luke@REDACTED
Thu Sep 26 15:46:38 CEST 2002
"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
More information about the erlang-questions
mailing list