[erlang-questions] import/1

[David Mercer]

Y'all will be thrilled to know I went ahead and whipped up this little parse
transform.  It can handle both -import(Module) directives and -unimport(...)
directives, in case you want to unimport a function that was mass-imported.
This example should explain usage:

	-module(example_import).

	-compile({parse_transform, import_enhancements}).

	-export([reverse/1, make_list/2]).

	-import(lists).
	-import(lists, [reverse/1]).  % This will result in an error unless
unimported.
	-unimport({lists,
		[ {last,1}    % unimports lists:last/1
		, {reverse,1} % unimports both imports of lists:reverse/1
		, {no_such_function/0} % ignored
		]}).

	%% Can now define our own reverse/1 function.
	%% This would error if both imports had not been undone.

	reverse(L) -> {reversed, lists:reverse(L)}.


	%% Can still use other lists functions that were not unimported.

	make_list(N, Elem) -> duplicate(N, Elem).


Note that this parse transform, while usually quiet, will be much more
chatty if passed the verbose option (e.g., if compiling from the Erlang
shell, something like, "c(Module, [verbose])."; if compiling with erlc, use
the "+verbose" option).

> -----Original Message-----
> From: David Mercer [mailto:dmercer@REDACTED]
> Sent: Friday, June 12, 2009 11:40 AM
> To: 'Joel Reymont'; 'Kostis Sagonas'
> Cc: 'Erlang'
> Subject: RE: [erlang-questions] import/1
> 
> I wrote:
> 
> >  Logic something like this: when
> > a local function call is found in a parse tree (i.e., {call, _, {atom,
> _,
> > FunName}), and if the function is not defined in the rest of the parse
> > tree nor in any explicit import (-import/2's), then modules imported by
> -
> > import/1's are checked to see if any of them have the function defined
> in
> > them, and, if so, the call is transformed to something like {call, _,
> > {remote, _, {atom, _, ModuleName}, {atom, _, FunName}}}.
> 
> Actually, I overcomplicated this.  Probably just need to transform
> {attribute,_,import,[ModuleName]} to
> {attribute,_,import,{ModuleName[...]}} after querying the BEAM for its
> exports.
> 
> 
> > -----Original Message-----
> > From: David Mercer [mailto:dmercer@REDACTED]
> > Sent: Friday, June 12, 2009 11:10 AM
> > To: 'Joel Reymont'; 'Kostis Sagonas'
> > Cc: 'Erlang'
> > Subject: RE: [erlang-questions] import/1
> >
> > Joel Reymont wrote:
> >
> > > On Jun 8, 2009, at 5:03 PM, Kostis Sagonas wrote:
> > >
> > > > What does it mean "to import all functions from a module" in a
> > > > language with hot-code loading when this set of functions can change
> > > > at anytime?
> > > > (and the compiler currently looks only at one module at a time)
> > >
> > >
> > > The functions exported from the module at compilation time.
> >
> > This can be done using a parse transform.  Logic something like this:
> when
> > a local function call is found in a parse tree (i.e., {call, _, {atom,
> _,
> > FunName}), and if the function is not defined in the rest of the parse
> > tree nor in any explicit import (-import/2's), then modules imported by
> -
> > import/1's are checked to see if any of them have the function defined
> in
> > them, and, if so, the call is transformed to something like {call, _,
> > {remote, _, {atom, _, ModuleName}, {atom, _, FunName}}}.
> >
> > > I can't see how -import() can work at runtime.
> >
> > It could work if you have only one -import/1.  In that case, the parse
> > transform described above doesn't bother checking whether the function
> > exists in the imported module, and automatically transforms it into the
> > remote call.  If you mess up, though, the error is pushed to runtime
> > rather than compile time, which is probably what you needed anyway, if
> you
> > really wanted runtime importing rather than compile-time.
> >
> > I don't need this parse transform, because I use HRL's as described in
> my
> > previous message, but this approach may have obviated my having to
> create
> > these HRL's.  The only catch is that sometimes I export functions from
> > modules that are not part of the interface that I intend to be imported;
> > while my HRL approach handles that, this implicit importing would
> probably
> > not handle it correctly.  (Well, you could make the parse transform
> check
> > an attribute in the BEAM that says what exported functions are not in
> the
> > imported interface.)
> >
> > Now that I think more about it, this might be a better way to go than my
> > HRL's.  Anyone see a problem with it?
> >
> > David
> >
> >
> > > -----Original Message-----
> > > From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED]
> > On
> > > Behalf Of Joel Reymont
> > > Sent: Monday, June 08, 2009 11:09 AM
> > > To: Kostis Sagonas
> > > Cc: Erlang
> > > Subject: Re: [erlang-questions] import/1
> > >
> > >
> > > On Jun 8, 2009, at 5:03 PM, Kostis Sagonas wrote:
> > >
> > > > What does it mean "to import all functions from a module" in a
> > > > language with hot-code loading when this set of functions can change
> > > > at anytime?
> > > > (and the compiler currently looks only at one module at a time)
> > >
> > >
> > > The functions exported from the module at compilation time.
> > >
> > > I can't see how -import() can work at runtime.
> > >
> > > ---
> > > Mac hacker with a performance bent
> > > http://www.linkedin.com/in/joelreymont
> > >
> > >
> > > ________________________________________________________________
> > > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > > erlang-questions (at) erlang.org