How does Lisp Flavored Erlang supports some features found in other Lisps

[Mário Guimarães]

Lisp Flavored Erlang (LFE) is a modern and promising Lisp running on top of the robust Erlang VM. Nevertheless, I have some questions regarding the level of support in LFE for some important features for which there are similar ones in other Lisp-like languages, e.g. Common Lisp:

- Is it possible in LFE to redefine a function, macro, or a module?

- What are the limitations of macros in LFE? Are they as powerful as in Common Lisp?

- What is the support in LFE for Aspect-Oriented Programming (AOP)? For example, in Common Lisp one can use :before, :after and :around to implement AOP. Please, give some links to AOP examples in LFE

- Is LFE's reader programmable, for example, like Common Lisp's reader is? Can I have user-defined reader macros in LFE?

Also, what are the limitations of using LFE when compared to Erlang for programing on the Erlang VM?

I would like to understand what is already in LFE supporting these questions before I deep dive into it.

Thanks
Mário

[Duncan McGreggor]

Robert will have to answer most of these, but I can address a few to get you started. See in-line, below:

On Fri, May 2, 2014 at 4:37 PM, Mário Guimarães <mario.luis...@gmail.com> wrote:

Lisp Flavored Erlang (LFE) is a modern and promising Lisp running on top of the robust Erlang VM. Nevertheless, I have some questions regarding the level of support in LFE for some important features for which there are similar ones in other Lisp-like languages, e.g. Common Lisp:

- Is it possible in LFE to redefine a function, macro, or a module?

Yes. However, some things won't be shadowed (the core forms, iirc).

 

- What are the limitations of macros in LFE? Are they as powerful as in Common Lisp?

Yup. Fully non-hygienic ;-) There's no gensym, but there are reasons why this may not be very useful in distributed systems. Robert has talked about this before (you can search the mail list for "gensym" to get some of those insights).

 

- What is the support in LFE for Aspect-Oriented Programming (AOP)? For example, in Common Lisp one can use :before, :after and :around to implement AOP. Please, give some links to AOP examples in LFE

LFE is really Erlang. LFE was created with the intent to be 100% compatible with Core Erlang and continues to get Core Erlang features. We're currently missing support for spec, but Robert thinks that an initial implementation of that would be fairly simple. We don't have types, debug_info support or dialyzer support yet -- that's pending some patches to OTP (to get AST into BEAM files). José Valim is working on this, last we heard from him.

Given that it's a Lisp with macro support, you can pretty much build anything you want. (Well, almost. There are always going to be limitations, even with a Lisp!). LFE is not a port of CL, so you won't see things like CLOS in LFE. However, you can pretty much build that, if you have the time, interest, and self-loathing (sorry, that was a joke... couldn't resist!). That sort of thing is always fun to explore. And I did something like it when I ported Peter Norvig's proto-OOP example from PAIP:

  https://github.com/rvirding/lfe/blob/master/examples/object-via-closure.lfe

However, to use Erlang idioms is going to be better LFE-style, so I also did an example of this functionality using processes:

  https://github.com/rvirding/lfe/blob/master/examples/object-via-process.lfe

It was quite enlightening, as a new Erlanger, to see how closures make to processes... really got Erlang to click for me.

I don't know anyone in the Erlang community doing AOP, and I haven't heard of anyone writing AOP macros for LFE, but it could very easily have happened without my knowledge :-)

 

- Is LFE's reader programmable, for example, like Common Lisp's reader is? Can I have user-defined reader macros in LFE?

Robert's rethinking some of the older parts of LFE that were created in 2008, and this is one of the areas he's been looking into, in the Rich Hickey "hammock" sense of "looking into" :-) He can give a better answer here.

 

Also, what are the limitations of using LFE when compared to Erlang for programing on the Erlang VM?

As mentioned above, LFE is 100% compatible with Core Erlang. We're not yet to 100% feature completeness, though. Getting close!

 

I would like to understand what is already in LFE supporting these questions before I deep dive into it.

I highly encourage some jumping in for fun, regardless :-) It's got a great feel, and at the very least, you'll have some fun!

d

 

Thanks
Mário

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Robert Virding]

This is mainly to confirm what Duncan has already written: LFE was designed to be 100% compatible with normal Erlang code and OTP. So you can use all of the standard libraries in LFE code and write callback modules for OTP behaviours in LFE. There are no problems with this. However, this has resulted in some properties/issues with LFE:

- LFE is not scheme nor CL, as neither can be efficiently implemented in Erlang and definitely not so the result would be compatible.
- Erlang code handling is based on modules which are the unit of code handling for compilation, loading and deleting. So you can't compile a single function. All code is compiled. Functions cannot have a variable number of arguments but you can define functions with the same name and different number of arguments which are then different functions.
- There is no support in erlang for macros so these are purely compiletime. But they are real lisp macros and you can do everything you would expect with them.
- LFE uses/supports the Erlang data types straight off, and these are not always compatible with say scheme or CL. For example there are no packages and atoms (symbols) are global.
- There is no global data in erlang.

A lot of these differences could have been implemented in LFE but then the erlang/OTP compatibility would have been lost. Everything you can do in Erlang you can do in LFE, except the new maps and I fixing them now.

If you look on github in doc/user_guide.txt there is a brief description of most of the features of LFE. And definitely check Duncan's LFE site http://lfe.github.io/ .

Robert

On Saturday, May 3, 2014 6:51:51 PM UTC+2, Duncan McGreggor wrote:

Robert will have to answer most of these, but I can address a few to get you started. See in-line, below:

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

[Mário Guimarães]

Hi,

so from what I understand from your answers, the goal of LFE is to provide a Lisp syntax and macros to Erlang, and nothing more. Is this correct? Or is there a wish to keep 100% compatibility with Erlang Core while moving forward its features and compete with Erlang?

Thanks

[Robert Virding]

Most definitely the second alternative.

We want the 100% compatibility to ensure efficiency and access to the whole OTP system and all the various packages that have been written for Erlang. We are now trying to ensure all the standard tools work with LFE. But of course this is not the end-goal. We will move LFE forward as we get new ideas and people come with interesting packages.

I am sceptical of extending the basic language as this could make compatibility difficult. Bit I feel lisp's innate extensibility makes this unnecessary.

I think that lisp together with Erlang concurrency and fault-tolerance is a very interesting and powerful combination, but it will probably entail rethinking how to implement things.

Robert

[Duncan McGreggor]

(Robert's email just came in as I was finishing this response; it looks like we're saying the same things, so that's a good sign! I'm sending mine anyway, in case it's helpful or good for a chuckle...)

On Sat, May 3, 2014 at 1:17 PM, Mário Guimarães <mario.luis...@gmail.com> wrote:

Hi,

so from what I understand from your answers, the goal of LFE is to provide a Lisp syntax and macros to Erlang

From what I understand from Robert, this was definitely the source of the original motivation.

 

, and nothing more.

That, well... I wouldn't go that far. LFE is a Lisp with Lisp macros; there is a LOT more than nothing :-)

 

Is this correct? Or is there a wish to keep 100% compatibility with Erlang Core while moving forward its features and compete with Erlang?

There is definitely strong driving force to maintain 100% compatibility with Erlang Core. Perhaps not a mandate for a future work, but I'm guessing there'd have to an amazing benefit to take on the burden of breaking Erlang compatibility.

To be clear, though: maintaining compatibility with Erlang is not really a big deal; it's not a limiting factor. There are all sorts of things you can do *on top of* an LFE that is Core Erlang-compatible. It may mean that the solution one planned for can't be done exactly as envisioned, but there's usually a way round to the same end result that can take an Erlang-compatible path.

We've been talking about doing all sorts of things with LFE that aren't necessarily in Erlang, but these would be either 3rd-party libs or part of a new LFE stdlib. One doesn't have to put everything in the core LFE language; new features and innovation can be done as macros, functions, or a combination of the two. (We are, at the same time, also making innovative changes to LFE core, just not as many, since that's not needed there so much.)

In summary: we are *very* much interested in innovation, exploration, and artistry. We just want to make sure that these great paintings take place on an easel, and not on the dinner table ;-)

d

 

Thanks

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Mário Guimarães]

Great to know that LFE is not just a new syntax to Erlang, but a true effort to go beyond Erlang while maintaining 100% compatibility with Core Erlang and its philosophy to concurrency and fault-tolerance.
And from what I understand, focus on Core Erlang also allows LFE code to be as performant as Erlang code is, which positions itself as a strong Lisp alternative on the Erlang VM.

I will keep an eye on the evolution of LFE, but perhaps it's better to start learning Erlang first to get to know the fundamentals of the platform, isn't it?

Thank you both for your answers, and keep on the good work in LFE.

Mário

[Duncan McGreggor]

On learning LFE and Erlang: I actually learned LFE first :-) Most Erlangers look at me weird when I say this... and take a few steps back from me. It took me longer to learn Erlang, but it allowed be to *really* dive into LFE quite deeply and without delay.

To be honest, I had such a resistance to Erlang syntax, that I was't going to learn it pretty much under any circumstances. LFE changed that :-) I now have a deep respect (verging on love) for Erlang and its concise, elegant idioms.

In other words, feel free to chose whichever approach suits you best, even if that approach looks to be the worst thing in the world to others ;-)

Oh, and you're very welcome! Thanks for asking such great question,

d

[Bernard Notarianni]

Hi guys,

I thank you very must for creating Erlang and LFE.

+1 to keep LFE small and elegant, as Erlang is.

Bernard.