[erlang-questions] import/1

[David Mercer]

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