[erlang-questions] import/1

David Mercer <>
Wed Jun 17 14:08:53 CEST 2009


I realize I am the only one contributing to this thread, but I tried out my
parse transform and now think it is the best thing since parameterized
modules.  That being said, I have made a change to it so that module_info/*
is not auto-imported by the -import(Module) directive.  This enables you to
import multiple modules in this manner without having to unimport
module_info.  Since I seem to be the only one interested in this, I am not
forwarding the source, but it is available at
https://bitbucket.org/dmercer/parsec-erlang/src/tip/src/import_enhancements.
erl if you are interested.

Cheers,

David

> -----Original Message-----
> From: David Mercer [mailto:]
> Sent: Tuesday, June 16, 2009 3:16 PM
> To: 'Joel Reymont'; 'Kostis Sagonas'
> Cc: 'Erlang'
> Subject: RE: [erlang-questions] import/1
> 
> 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:]
> > 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:]
> > > 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:  [mailto:erlang-
> ]
> > > 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



More information about the erlang-questions mailing list