LFE vs Elixir

[Josh]

I'm curious about how the capabilities of LFE and Elixir differ, and I can't seem to find any good information on it.  I realize the syntax is quite different, but I'm curious more on the level of actual language features.  Does anyone have any insight on this?

[rvirding]

To answer this question I think that it is important to look at the similarities between the languages:

- Both LFE and Elixir have the explicit goal to be compatible with vanilla erlang in the sense that you can freely mix code written in any dialect. So, for example, it is problem free to write behaviour code in LFE/Elixir and use it together with all of OTP. This allows LFE/Elixir code to be used as components of larger systems written in vanilla erlang.

- Both LFE and Elixir support the same datatypes as vanilla erlang. Seeing they both run on top of erlang it is not possible for them to create new datatypes.

- Both LFE and Elixir compile down to the same code as vanilla erlang generates. Elixir does this by compiling to vanilla erlang while LFE compiles down to Core erlang which is an internal language in the compiler. This means that there is no performance penalty in using either LFE or Elixir.

There are of course differences as well:

- LFE is very true to how vanilla erlang handles datatypes while Elixir has made some changes to which types are "standard". So LFE still has strings as lists of characters while Elixir has strings as binaries by default.

- Elixir has done some work in improving the interfaces to some standard libraries while LFE uses the standard libraries "straight".

- While Elixir has a much improved macro handling it is still limited by only allowing its predefined syntax. LFE as a lisp has no predefined syntax only lists so macros can be, and often are, used to define new syntax. LFE uses macros to implement records.

So in one sense you can say that there is no real need for either LFE or Elixir at the lowest level they can only do what vanilla erlang can do. But many people feel they can do it in a much better way.

In the end it probably boils down to which syntax you prefer: the lisp syntax of LFE or the Rubish syntax of Elixir. Personally, I am a lover of parentheses.

Robert

[Duncan McGreggor]

Quick correction below!

Sent from an iPad

On Jun 24, 2013, at 6:38 PM, rvirding <rvir...@gmail.com> wrote:

To answer this question I think that it is important to look at the similarities between the languages:

- Both LFE and Elixir have the explicit goal to be compatible with vanilla erlang in the sense that you can freely mix code written in any dialect. So, for example, it is problem free to write behaviour code in LFE/Elixir and use it together with all of OTP. This allows LFE/Elixir code to be used as components of larger systems written in vanilla erlang.

- Both LFE and Elixir support the same datatypes as vanilla erlang. Seeing they both run on top of erlang it is not possible for them to create new datatypes.

- Both LFE and Elixir compile down to the same code as vanilla erlang generates. Elixir does this by compiling to vanilla erlang while LFE compiles down to Core erlang which is an internal language in the compiler. This means that there is no performance penalty in using either LFE or Elixir.

There are of course differences as well:

- LFE is very true to how vanilla erlang handles datatypes while Elixir has made some changes to which types are "standard". So LFE still has strings as lists of characters while Elixir has strings as binaries by default.

- Elixir has done some work in improving the interfaces to some standard libraries while LFE uses the standard libraries "straight".

- While Elixir has a much improved macro handling it is still limited by only allowing its predefined syntax. LFE as a lisp has no predefined syntax only lists so macros can be, and often are, used to define new syntax. LFE uses macros to implement records.

So in one sense you can say that there is no real need for either LFE or Elixir at the lowest level they can only do what vanilla erlang can do. But many people feel they can do it in a much better way.

In the end it probably boils down to which syntax you prefer: the lisp syntax of LFE or the Rubish

Robert definitely means "Ruby" here! 

(Looks like he was nabbed by the autocorrect demon :-/ )

Also, Robert: that was a completely lovely write-up. That would make a nice blog post!

d

syntax of Elixir. Personally, I am a lover of parentheses.

Robert


On Monday, June 24, 2013 4:26:04 PM UTC+2, Josh wrote:

I'm curious about how the capabilities of LFE and Elixir differ, and I can't seem to find any good information on it.  I realize the syntax is quite different, but I'm curious more on the level of actual language features.  Does anyone have any insight on this?

--
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/groups/opt_out.
 
 

[Josh]

This is exactly the kind of information I was looking for.  Thank you!

[José Valim]

As expected, Robert comments are very accurate. :)

Of the three goals I had in mind for Elixir (productivity, extensibility and compatibility), LFE nails two of them out of the box: productivity and compatibility. The remaining goal, extensibility, is achieved in Elixir via protocols, and they would be easy to implement in LFE if one desires to, since both languages have macros.

I'd just like to extend Robert's response to mention the work we have done in Elixir's standard library. The standard library has UTF-8 Strings, which supports many operations as defined per the Unicode Standard (and more performant than the libraries available today), it supports Ranges, conveniences for working with URIs and manipulating files, an unified API for working with Dictionaries, as well as a faster hash dict implementation (and soon a hash set implementation too). With Elixir you will also get Elixir's Interactive Shell (iex) and the Mix tool, for building, compiling and testing your projects.

Of course, since everything simply compiles to Erlang bytecode, there is nothing stopping you from using all of that directly from LFE too. :)

[rvirding]

I know of Elixir's protocols and the Unicode work and they are definitely something I will look into. I am completely unprejudiced and will happily steal good ideas from anyone. :-)

Robert

[lavokad l]

hi Robert, I can't figure out what you mean with " While Elixir has a much improved macro handling it is still limited by only allowing its predefined syntax.". Can you can give a small example to illustrate this case. Thanks in advance

[Robert Virding]

What I mean here is that elixir has a predefined syntax. It has a number of predefined syntactic constructs, operators and function calls. And while I can with macros change the meaning of the constructs I cannot add new constructs or operators as the handling of macros is done after parsing. So if I want to add something completely new it ends up syntactically being a function call. Now elixir has many ways of disguising function calls at the end of the day they are syntactically still function calls. For example parentheses around arguments are optional, there is special syntax for property lists where the keys are all atoms, special syntax for using these property lists as function arguments, special handling of do ... end when it is a function argument, etc. Elixir's uniform abstract syntax makes it easier to work with these but I am still limited by only having the existing syntax.

For example assume I work a lot with property lists where the keys are integers, or I would like to have keys with are either atoms or integers, then there is no way for me to create a special syntax for this at all. Even if I have macros.

Lisp, however, has a completely free syntax, or some would say no syntax at all, so I am almost completely free to interpret the sexps as I like. Basically the only restriction is that first element of the form/list says what it is. You could also say *everything* looks like a function call. So for example if I want to make a special form for a list of key-value pairs where it keys are literal terms while values are evaluated I can easily do this:

(defmacro kl
  ((list* k v rest) `(cons (tuple ',k ,v) (kl ,@rest)))
  (() ()))

which I can use

(kl a (+ 2 7) b 6) ==> (#(a 9) #(b 6))

This is what I mean by elixir being limited by only allowing its predefined syntax.

Robert

[Duncan McGreggor]

Oh, wow -- thanks, Robert! That helped me out, too... that's a good read.

d

--

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.

[Raoul Duke]

I think perhaps maybe possibly things like nemerle and haxe (and
intentional software) try to get around that while having "m-expr"
style syntax :-)

[Robert Virding]

What is it with infix operators? Watch out so I don't convert it all to RPN and so we write everything in forth. :-)

Robert

P.S. Actually forth syntax is very tempting, maybe my next language?

[Duncan McGreggor]

/me  laughs

I don't doubt it one bit :-)

--