> Here are some things which are in my immediate pipeline for LFE:

> - The interpreter, lfe_eval, does not handle macro expansion properly,
> fix this.
> - Guards are a mess now if you want more complex guards, it's not at
> all clear, fix this.
> - Improve the user_guide.txt documentation adding a new section on
> guards and generally just more.
> - When OTP is properly available convert all documentation to use it.
> I am not a fan of edoc!
> - Try to make calling functions in other modules look better and more
> natural.

> The last one is a bit tricky. While (: mod func ...) is trivial as a
> macro and naturally maps onto the general (call 'mod 'func ...) (which
> will remain) it definitely looks "odd". Exactly how I am going to fix
> it I don't know. Today there is a provision to write in defmodule
> (import (prefix foo "foo:")) but it is ignored as yet. It would allow
> you to define *any* prefix which would map the call to a call to
> another module. So

> (defmodule foo (import (prefix bar "bar//")) ...)

> (defun ...
>   ...
>   (bar//sune ...)
>   ...)

> would map the call to (call 'bar 'sune ...). It is very nice and
> general but like normal imports it does require you to explicitly do
> it. An alternative would be to always map (foo:bar ...) to (call 'foo
> 'bar ...) but I haven't yet thought this through to see if it
> introduces any strangeness.

> I will have to get back on this one. All suggestions welcome.

> Robert

> Hi,

> I have come up with a little macro for doing module imports.

> Posted here:http://gist.github.com/306323

> I'll let you look at the code, but pretty much you use it like:
> (import-module foo)

> And then it finds all of the exported functions in that module, and
> creates a macro foo:fn-name for each, which expands into the form

> (call 'module 'fn-name ,@args)

> It would be pretty simple to expand it to do prefix renaming or use
> something other than ":" etc.

> Of course you are welcome to use any/all of the code I posted if it
> will help!

> -Jon

> On Feb 3, 6:36 am, rvirding <rvird...@gmail.com> wrote:

> > Here are some things which are in my immediate pipeline for LFE:

> > - The interpreter, lfe_eval, does not handle macro expansion properly,
> > fix this.
> > - Guards are a mess now if you want more complex guards, it's not at
> > all clear, fix this.
> > - Improve the user_guide.txt documentation adding a new section on
> > guards and generally just more.
> > - When OTP is properly available convert all documentation to use it.
> > I am not a fan of edoc!
> > - Try to make calling functions in other modules look better and more
> > natural.

> > The last one is a bit tricky. While (: mod func ...) is trivial as a
> > macro and naturally maps onto the general (call 'mod 'func ...) (which
> > will remain) it definitely looks "odd". Exactly how I am going to fix
> > it I don't know. Today there is a provision to write in defmodule
> > (import (prefix foo "foo:")) but it is ignored as yet. It would allow
> > you to define *any* prefix which would map the call to a call to
> > another module. So

> > (defmodule foo (import (prefix bar "bar//")) ...)

> > (defun ...
> >   ...
> >   (bar//sune ...)
> >   ...)

> > would map the call to (call 'bar 'sune ...). It is very nice and
> > general but like normal imports it does require you to explicitly do
> > it. An alternative would be to always map (foo:bar ...) to (call 'foo
> > 'bar ...) but I haven't yet thought this through to see if it
> > introduces any strangeness.

> > I will have to get back on this one. All suggestions welcome.

> > Robert

On Tue, Mar 2, 2010 at 5:09 PM, rvirding <rvird...@gmail.com> wrote:
> I should have commented this earlier.

> This is a nice idea, it sort of works backwards to how I had
> envisioned (prefix ...) to work. It is definitely easier to implement
> and much more efficient for the interpreter as it generates macros.
> Very good for libraries. I would extend it be used like:
> (import-module foo foo:)

> with an explicit prefix but I tend to overgeneralise. Maybe prefix
> should work like this.

> The only problem with both of them is that they are specific to
> certain modules, the ones they are called with, and are not general
> like : is in vanilla.

> What do you think?

> Robert

> On Feb 17, 6:33 am, Jonathan Smith <jonathansmith...@gmail.com> wrote:
> > Hi,

> > I have come up with a little macro for doing module imports.

> > Posted here:http://gist.github.com/306323

> > I'll let you look at the code, but pretty much you use it like:
> > (import-module foo)

> > And then it finds all of the exported functions in that module, and
> > creates a macro foo:fn-name for each, which expands into the form

> > (call 'module 'fn-name ,@args)

> > It would be pretty simple to expand it to do prefix renaming or use
> > something other than ":" etc.

> > Of course you are welcome to use any/all of the code I posted if it
> > will help!

> > -Jon

> > On Feb 3, 6:36 am, rvirding <rvird...@gmail.com> wrote:

> > > Here are some things which are in my immediate pipeline for LFE:

> > > - The interpreter, lfe_eval, does not handle macro expansion properly,
> > > fix this.
> > > - Guards are a mess now if you want more complex guards, it's not at
> > > all clear, fix this.
> > > - Improve the user_guide.txt documentation adding a new section on
> > > guards and generally just more.
> > > - When OTP is properly available convert all documentation to use it.
> > > I am not a fan of edoc!
> > > - Try to make calling functions in other modules look better and more
> > > natural.

> > > The last one is a bit tricky. While (: mod func ...) is trivial as a
> > > macro and naturally maps onto the general (call 'mod 'func ...) (which
> > > will remain) it definitely looks "odd". Exactly how I am going to fix
> > > it I don't know. Today there is a provision to write in defmodule
> > > (import (prefix foo "foo:")) but it is ignored as yet. It would allow
> > > you to define *any* prefix which would map the call to a call to
> > > another module. So

> > > (defmodule foo (import (prefix bar "bar//")) ...)

> > > (defun ...
> > >   ...
> > >   (bar//sune ...)
> > >   ...)

> > > would map the call to (call 'bar 'sune ...). It is very nice and
> > > general but like normal imports it does require you to explicitly do
> > > it. An alternative would be to always map (foo:bar ...) to (call 'foo
> > > 'bar ...) but I haven't yet thought this through to see if it
> > > introduces any strangeness.

> > > I will have to get back on this one. All suggestions welcome.

> > > Robert

> --
> You received this message because you are subscribed to the Google Groups
> "Lisp Flavoured Erlang" group.
> To post to this group, send email to
> lisp-flavoured-erlang@googlegroups.com.
> To unsubscribe from this group, send email to
> lisp-flavoured-erlang+unsubscribe@googlegroups.com<lisp-flavoured-erlang%2B unsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/lisp-flavoured-erlang?hl=en.

> The generalized prefix would be fairly easy to add to it.
> The only issue I really would have with it was that I can't think of a use
> case where it is really advantageous.
> (Perhaps if you have a particularly long module name, but generally Erlang
> module names seem to be fairly concise).

> Even so,  being able to change between "//" and ":" and whatever might get
> a little confusing. Therefore, I would prefer to see ":" used as the module
> prefix and the function name of choice, just because it is consistent with
> the lisps I've used (and Erlang as well), so it has an intuitive meaning to
> me.  Being able to alias the just the module prefix, might be useful on its
> own, as it would take care of any potential
> 'module_name_is_too_long_to_type_comfortably' problems.

> So you might end up with something like:

> (import-module foo_is_long foo)
> to import the 'foo_is_long' module as foo:fn-name*
> and
> (import-module short)
> to import the 'short' module as short:fn-name*

> I like the vanilla : as well, and that is what I initially wanted to use,
> however, it was beyond my abilities to write a macro that does that.
> (I think it would have required a parser tweak).

> That said, it is good having a record in the header which indicates what
> external libraries/modules are being used in a given .lfe file, specifically
> if you are using libraries that *aren't* in the core distribution of
> Erlang (we could check for them and make sure to load them). It might also
> be a useful thing to have around if namespaces(?) are included in Erlang at
> some point, although I'm not up to date on how those are planned to work.

> Anyway,
> Hope this helps,

> -Jon

> On Tue, Mar 2, 2010 at 5:09 PM, rvirding <rvird...@gmail.com> wrote:

>> I should have commented this earlier.

>> This is a nice idea, it sort of works backwards to how I had
>> envisioned (prefix ...) to work. It is definitely easier to implement
>> and much more efficient for the interpreter as it generates macros.
>> Very good for libraries. I would extend it be used like:
>> (import-module foo foo:)

>> with an explicit prefix but I tend to overgeneralise. Maybe prefix
>> should work like this.

>> The only problem with both of them is that they are specific to
>> certain modules, the ones they are called with, and are not general
>> like : is in vanilla.

>> What do you think?

>> Robert

>> On Feb 17, 6:33 am, Jonathan Smith <jonathansmith...@gmail.com> wrote:
>> > Hi,

>> > I have come up with a little macro for doing module imports.

>> > Posted here:http://gist.github.com/306323

>> > I'll let you look at the code, but pretty much you use it like:
>> > (import-module foo)

>> > And then it finds all of the exported functions in that module, and
>> > creates a macro foo:fn-name for each, which expands into the form

>> > (call 'module 'fn-name ,@args)

>> > It would be pretty simple to expand it to do prefix renaming or use
>> > something other than ":" etc.

>> > Of course you are welcome to use any/all of the code I posted if it
>> > will help!

>> > -Jon

>> > On Feb 3, 6:36 am, rvirding <rvird...@gmail.com> wrote:

>> > > Here are some things which are in my immediate pipeline for LFE:

>> > > - The interpreter, lfe_eval, does not handle macro expansion properly,
>> > > fix this.
>> > > - Guards are a mess now if you want more complex guards, it's not at
>> > > all clear, fix this.
>> > > - Improve the user_guide.txt documentation adding a new section on
>> > > guards and generally just more.
>> > > - When OTP is properly available convert all documentation to use it.
>> > > I am not a fan of edoc!
>> > > - Try to make calling functions in other modules look better and more
>> > > natural.

>> > > The last one is a bit tricky. While (: mod func ...) is trivial as a
>> > > macro and naturally maps onto the general (call 'mod 'func ...) (which
>> > > will remain) it definitely looks "odd". Exactly how I am going to fix
>> > > it I don't know. Today there is a provision to write in defmodule
>> > > (import (prefix foo "foo:")) but it is ignored as yet. It would allow
>> > > you to define *any* prefix which would map the call to a call to
>> > > another module. So

>> > > (defmodule foo (import (prefix bar "bar//")) ...)

>> > > (defun ...
>> > >   ...
>> > >   (bar//sune ...)
>> > >   ...)

>> > > would map the call to (call 'bar 'sune ...). It is very nice and
>> > > general but like normal imports it does require you to explicitly do
>> > > it. An alternative would be to always map (foo:bar ...) to (call 'foo
>> > > 'bar ...) but I haven't yet thought this through to see if it
>> > > introduces any strangeness.

>> > > I will have to get back on this one. All suggestions welcome.

>> > > Robert

>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lisp Flavoured Erlang" group.
>> To post to this group, send email to
>> lisp-flavoured-erlang@googlegroups.com.
>> To unsubscribe from this group, send email to
>> lisp-flavoured-erlang+unsubscribe@googlegroups.com<lisp-flavoured-erlang%2B unsubscribe@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/lisp-flavoured-erlang?hl=en.