
Lisp Flavoured Erlang 1.0 released after 8 years of development - vdaniuk
https://github.com/rvirding/lfe
======
eggy
Great news! I wanted to learn BEAM/OTP, but had tried Erlang briefly years
ago, and then went back to Common Lisp. Now I can try to learn BEAM/OTP in a
syntax that is more appealing to me than Elixir's Ruby-like syntax. I like
Elixir, and it is very popular, but true runtime macros are available in LFE
1.0. In addition, Robert Virding was one of the co-creators of Erlang, so his
devotion to bringing the best Lisp he could to the BEAM platform within its
confines, comes with some authority. The Google Group Lisp Flavoured Erlang is
a very responsive community and resource for getting started. Congratulations
LFE on your v1.0! OT, but I also use Extempore - the music, graphics
livecoding environment with a great language, xtlang that I believe was based
upon S7 scheme and has an LLVM backend [1]. There are some s-expression to
WebAssembly projects floating around too. All around good news for all the
choices to work with up front no matter your preferences.

    
    
       [1]  http://extempore.moso.com.au/

~~~
sjtgraham
Elixir is really not similar to Ruby and the comparison wears thin. This is my
opinion after having used Elixir daily for the last 1.5 years and Ruby for 10
years before that.

Elixir really is a brilliant language and José et al have made the developer
experience second to none with hex, mix, the language guide and docs. Compare
how you bring up a repl: Elixir, type iex; LFE, cd into LFE dir, type
./bin/lfe. (EDIT: this is incorrect, see child) Trivial example and something
easily fixed if it bothers you, but it's emblematic of the attention to detail
that has gone into devx. I am deeply in love with Elixir. That Robert co-
authored Erlang should not mean giving Elixir any less consideration IMO.

That said I sincerely wish to congratulate Robert on this 1.0, I look forward
to using LFE in anger for something very soon now it is 1.0 (and it will be
easy to slip in an LFE module into one of my OTP apps). Exciting times for the
Erlang ecosystem.

~~~
masklinn
> Compare how you bring up a repl: Elixir, type iex; LFE, cd into LFE dir,
> type ./bin/lfe.

Is that a joke?

> If you have installed LFE, then you may start the REPL from any location:
    
    
         $ lfe
    

what you quoted is if you're running LFE straight from the git clone[0], and
noted so.

[0] because you may not want a system-wide LFE and LFE is being a nice citizen
in explicitly supporting that use case.

~~~
philjackson
In actual fact, the LFE installation experience was a breath of fresh air:

    
    
        $ brew install erlang
        $ git clone ...lfe.git
        $ cd lfe; make && make install
    
        $ lfe
    

I miss make.

~~~
masklinn
FWIW that can be further simplified to just `brew install lfe`:
[https://lfe.gitbooks.io/quick-
start/content/1.html#1-2-1-hom...](https://lfe.gitbooks.io/quick-
start/content/1.html#1-2-1-homebrew)

~~~
oubiwann
Not only that, but an hour after your post, someone (burma-shave) had updated
the LFE formula for v1.0 of LFE: *
[https://github.com/Homebrew/homebrew/blob/f95c192d43d9a56bda...](https://github.com/Homebrew/homebrew/blob/f95c192d43d9a56bdaa67b8268c76310afacb96c/Library/Formula/lfe.rb)

------
vdaniuk
Robert Virding has just announced the release on twitter
[https://twitter.com/rvirding/status/710259707819249664](https://twitter.com/rvirding/status/710259707819249664)

I feel that this LFE release further validates BEAM as a promising platform
for future development of new programming languages. Also I look forward to
reading SICP converted to LFE. Available chapters can be found here
[https://www.gitbook.com/book/lfe/sicp](https://www.gitbook.com/book/lfe/sicp)

~~~
emmanueloga_
Given you mentioned SICP... SICP is cool for its math and its puzzle-like
problems, but I found [http://scheme.com/tspl4/](http://scheme.com/tspl4/) a
much better introduction to Scheme and more likely to help me solve problems
with Scheme in the real world (i.e. a good reference book).

------
akavel
I've stumbled into an interesting related comment on twitter, didn't know:

 _" #Erlang based language ecosystem is more diverse than many know: #efene
#reia #lfe #luaerl #erlog #elixir #mercury"_

[https://twitter.com/BillBarnhill/status/670601359016771584](https://twitter.com/BillBarnhill/status/670601359016771584)

 _edit:_ Wow, and many of them seem to actually be by the same rvirding who
authored lfe:

[https://github.com/rvirding/luerl](https://github.com/rvirding/luerl)

[https://github.com/rvirding/erlog](https://github.com/rvirding/erlog)

~~~
vvanders
Shame about luerl not supporting __metatable properly. That's half of why Lua
is awesome.

Still a massive achievement, awesome stuff.

~~~
rvirding
Main issue is that luerl does support metatables. That caveat was written ago
and I can't remember what it was I didn't support then. But as I said now it
works.

~~~
vvanders
Kudos! That's really awesome then.

I've got a lot of love for Lua(works great in embedded spaces, we use to do
game logic in ~400kb block on a PSP with ~8mb of RAM).

Metatables are such an great way of exposing composability without putting a
lot of restrictions on how the language works.

------
rvirding
I do want to point out that LFE has been release ready and of production
quality for a long time but I tend to suffer from a "Jag ska bara"* syndrome
which has delayed things. :-)

* I am just going to ...

~~~
piokuc
Thank you so much for this wonderful stuff!

------
Kuytu
Robert Virding gave a short talk on LFE at ClojuTRE last year:
[https://www.youtube.com/watch?v=BvCBTpnlqs8](https://www.youtube.com/watch?v=BvCBTpnlqs8)

------
hellofunk
Virding's YouTube presentation at a Clojure conference about this new lisp
says this in the caption:

>LFE (Lisp Flavoured Erlang) has been designed to run efficiently on the
Erlang VM and at the same time be a "real lisp" providing Lisp's good bits.

It also knocks Clojure a bit. What do you all think are the "good bits" of
lisp that Clojure lacks?

~~~
kaeluka
FWIW, reading this sentence w/o any extra context, it doesn't seem to imply
anything bad about clojure.

~~~
hellofunk
The bit about Clojure was additional information in the source that I did not
quote.

------
jarpineh
This looks really interesting. I installed it easily through Brew. REPL seems
to work fast.

Now if my Clojure flawored Lisp starter level knowledge could be somehow
transformed into Erlang flawor...

I wrote this:

    
    
        > (map (lists:seq 1 10) (lambda (a) (io:format a)))
    

and this happened:

    
    
        #M((1 2 3 4 5 6 7 8 9 10) #Fun<lfe_eval.12.88887576>)
    

So, I'm not quite there yet. Hopefully somebody can make a Clojure to LFE
comparison.

And using Elixir based things like Phoenix springs to mind...

~~~
strmpnk
Map is a constructor in this case. You'll want lists:map/2 (fn comes first). I
don't know LFE much so there may be sugar of sorts for this, perhaps a
comprehension syntax.

~~~
rvirding
Yes, there are list comprehensions but they return the list of values:

(lc ((<\- x (lists:seq 1 10))) (lfe_io:format "~p" x))

~~~
jarpineh
Thank you both. I didn't realize how Erlang flawored this really is. This did
the trick:

    
    
        > (lists:map (lambda (a) (io:format (integer_to_list a))) (lists:seq 1 10))
    

Though all those OKs look kind of superfluous. I must read Erlang tutorial or
two before I proceed.

~~~
macintux
io:format is a side-effecting function. It prints to the terminal. The atom ok
is the return value.

If you want to create a list of strings, this works:

    
    
        > (lists:map (lambda (a) (lists:flatten (io_lib:format "~B" (list a)))) (lists:seq 1 10)).
        ("1" "2" "3" "4" "5" "6" "7" "8" "9" "10")

------
namelezz
> A proper Lisp-2, based on the features and limitations of the Erlang VM

What are limitations?

~~~
jsnell
One obvious example is that AFAIK the VM doesn't support functions with a
variable number of arguments (foo/1 and foo/2 are two separate functions).
This means that you can't have CL-style &rest or &key arguments.

~~~
StreamBright
This is a feature to me more like a limitation. I do not like optional
arguments &rest style. In Erlang you need to have explicit number of arguments
and need to explicitly implement them. I really like that. Keep in mind that
default values are trivial to implement when the smaller arity function calls
the higher arity one with added values. Or you can call in yourself to the
higher arity function and specify the parameters yourself. In my opinion this
is elegant and safe way of dealing with the problem.

~~~
seiji
_In Erlang you need to have explicit number of arguments and need to
explicitly implement them._

Or, you know, just use lists as parameters. That's the standard Erlang pattern
for unknown parameters lengths (e.g. io:format("debug ~s because ~p~n",
[SomeString, SomeType]))

~~~
kazinator
Firstly, this still requires a mechanism which underlies the [ ... ] notation
for evaluating a sequence of any number of expressions and constructing a
list.

In Lisp dialects, that is done by a variadic function:

    
    
      (list 1 2 3 4 ...)
    

Of course, if we don't need to indirect on this function, we could implement
it as a macro (supposing further that we have variadic macros for compile
time, but not variadic functions for run time).

The macro would turn (list 1 2 3) into the non-variadic calls (cons 1 (cons 2
(cons 3 nil))).

I imagine that's a conceptual facsimile of what Erlang's list constructor
notation is doing.

Erlang has variadic features in its read syntax; without a doubt its BNF is
chock full of "zero or more of ..." grammar productions. The function defining
mechanism lets you define a function which has any number of arguments; just
that number has to be fixed for that function. So the mechanism itself enjoys
variadic application. Here it is asked to define a three-arg function, here a
ten-arg, ...

We can simulate some aspects of variadic application with syntactic sugar, but
not all. A Lisp function call which specifies five arguments can call a
function which requires exactly five arguments, or a function which requires
three arguments, followed by variadic ones.

For instance, if we have a callback registration interface that passes five
arguments, the client can supply a fixed arity function, or a variadic one.

I suppose that if everything is static, that can still be worked out. The
compiler sees that a variadic function with only two required args is passed
as a callback that must be 5-ary, so it inserts a conversion shim: an
anonymous function which takes exactly 5 parameters and applies them to the
3+rest function.

~~~
rvirding
LFE macros can have variable number of arguments. The compiler does very
little in helping with this as there are in principle no inter-module
dependencies. This is a requirement of the dynamic code handling which allows
you to reload any module at any time without any requirements on the contents.
All checking is done at run-time. This is a basic property of the Erlang
system and to make something which is fully compatible you have to follow
this.

One way to have made LFE fully variadic in its functions would have been to
have made each function only take one argument which is a list of the
arguments in the call. This would have been easy to do but made it very
difficult to interface LFE with the rest of the Erlang system in a clean way.

------
aidenn0
The users manual has a stub section for macros; does anybody know how LFE
macros work? It says "lisp style" but that allows at least 4 options (syntax
pattern-matching versus classic defmacro, and capturing versus non-capturing).

~~~
aweinstock
There's some more in-depth documentation in the repo in doc/user_guide.txt, at
around line 520-ish.

It has Common Lisp style defmacro (augmented with pattern matching), and
Scheme-inspired defsyntax. The documentation warns that both are unhygienic,
and `grep -ri gensym` didn't find anything in the repo.

~~~
aidenn0
So I guess you just have to be super careful with variable and function names?
That's the dark-ages for lisp, but still usable.

------
clw8
My exposure to the Erlang world is limited to having read the first few
chapters of Programming Elixir. Is interop trivial? Can you easily use Erlang,
Elixir, and LFE in the same project?

~~~
lpil
Yes, compiling a module where the source was written in another language is no
different from calling a module written in the same one. In Elixir any time
you call a module that starts with a `:` it has most likely been written in
Erlang.

~~~
sjtgraham
Technically all modules begin with : as module references are atoms. iex just
hides it from for Modules made with defmodule (they have :Elixir prepended to
them) /trivia

------
im_down_w_otp
The docs are sadly very incomplete still. :-(

How do I go about sponsoring a technical writer to complete them?

------
philjackson
I'd love to see a comparison with Clojure, anyone know of such a thing yet?

~~~
oubiwann
It's a work in progress, but this might be useful:

* [http://lfex.github.io/hyperpolyglot/](http://lfex.github.io/hyperpolyglot/)

~~~
philjackson
Great - thanks.

------
alberth
Slightly off topic: does anyone have an update on BEAM JIT?

------
andrewvijay
Just waiting for the day when someone launches a js version then the whole
world is gonna be coding on erlang vm I think.

~~~
sjtgraham
I doubt it. IMO Erlang is fundamentally a different model of programming than
JS and what about mutability and things such as pattern matching? It quickly
becomes apparent that it would not be much like JS if it was to take advantage
of all of Erlang's best bits.

~~~
koder2016
Exactly, Erlang is a DSL for distributed applications. There is not much point
to use it for anything else.

~~~
tazjin
Erlang and related languages are applicable for most long-running
applications.

The amount of people who actually use true distributed Erlang is probably
small, because you get many of the benefits either way.

------
diskcat
Could you believe that 2016 is the year of the beginning of the LISP
renaissance.

Im going to buy some spare paren keys, they might become scarce in the
immediate future.

~~~
macmac
It started in 2007 with the release of Clojure and there are still plenty of
paren keys around.

~~~
lispm
The Lisp renaissance started in December 1999 with SBCL being forked from
CMUCL.

~~~
jhbadger
On the other hand, 1999 was the downfall of LISP in the statistical community
because that's when Luke Tierney decided to stop working on LISP-STAT, a LISP
dialect with extensions for statistics that was semi-popular before the advent
of R. While there have been statistical systems based on LISP since (such as
Incanter for Clojure and a port of many of the extensions of LISP-STAT to
Common Lisp) none have managed to make a dent against R, unfortunately.

~~~
lispm
That was the consequence of users switching to S/R years before.

[https://www.jstatsoft.org/article/view/v013i07/v13i07.pdf](https://www.jstatsoft.org/article/view/v013i07/v13i07.pdf)

Users of maths software usually don't want to use Lisp syntax and are not
ready to work in Lisp.

XLisp-Stat had also the problem that it used its own Lisp implementation,
based on XLisp (upto Xlisp 2), which itself wasn't going anywhere. David Betz,
the original author of Xlisp, rewrote Xlisp as a form of Scheme (Xlisp 3.0)
and it died eventually. Xlisp-Plus, another Xlisp version, was mostly
abandoned also in that timeframe - though there are updated versions available
now.

Other math software, which had been ported to Common Lisp, is still maintained
- like Maxima. The maintainers can concentrate on the application and the code
is much easier portable to new systems because of a choice of implementations.

Had XLisp-Stat been fully ported to Common Lisp (actually a rough port of the
Xlisp-Stat core to Common Lisp was done many years ago) and maintained there -
at least the code would still be easier usable.

~~~
oubiwann
Having used early versions of Mathematica in university, I'm actually a huge
fan of Maxima (a fork of Macsyma, the latter having been the principle
inspiration behind Mathematica). I have it installed on several systems and
use it now for all the things I used to use Mathematica. In fact, the CL
source code for rational numbers in Maxima formed the basis of similar work in
LFE (the horatio project).

I was very sad to find out that Xlisp-Stat had not been ported and maintained
in CL :-/ ... perhaps a good project for a motivated, if fringe, *SoC project
:-)

~~~
lispm
This is a Common Lisp version of the Xlisp-Stat core from 1996:

[http://homepage.stat.uiowa.edu/~luke/xls/xlispstat/other/CL/](http://homepage.stat.uiowa.edu/~luke/xls/xlispstat/other/CL/)

