Parse transformery (Was: Re: Calling internal functions - foo::bar() ?)

Luke Gorrie luke@REDACTED
Tue Mar 8 02:39:37 CET 2005


Kostis Sagonas <kostis@REDACTED> writes:

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

I can compile this module:

  -module(x).
  -compile({parse_transform,internal_exports}).

  a() -> working.
  z(X) -> {ok, X}.

and I can call its internal functions in the shell:

  5> x:a().
  working
  6> x:z(42).
  {ok,42}

but they are not really exported. The trick is based on the one that
Erik Stenman sent me when we had this thread years ago:

  7> x:'EXPORTER'().
  [{{a,0},#Fun<x.0.15689079>},{{z,1},#Fun<x.1.108540428>}]

i.e. the parse transform has synthesized an 'EXPORTER' function that
returns funs for everything.

Of course I have hacked the shell to support this interface (patch
below) but it can also be used in a more klunky way:

  8> internal_exports:apply(x, a, []).
  working

which might be bearable with this user_default function:

  iapply(M, F, A) -> internal_exports:apply(M, F, A).

but I'll stick with the customized shell for now.

The parse transform is lib/msc/src/internal_exports.erl in jungerl.

Cheers,
Luke

P.S. Good luck Mats on getting this adopted for AXD301. :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: erl_eval.patch
Type: text/x-patch
Size: 1204 bytes
Desc: internal_exports patch to erl_eval.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20050308/86c06ab4/attachment.bin>


More information about the erlang-questions mailing list