[1] http://extempore.moso.com.au/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.
Is that a joke?
> If you have installed LFE, then you may start the REPL from any location:
$ lfe
[0] because you may not want a system-wide LFE and LFE is being a nice citizen in explicitly supporting that use case.
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
"#Erlang based language ecosystem is more diverse than many know: #efene #reia #lfe #luaerl #erlog #elixir #mercury"
https://twitter.com/BillBarnhill/status/670601359016771584
edit: Wow, and many of them seem to actually be by the same rvirding who authored lfe:
Still a massive achievement, awesome stuff.
* I am just going to ...
>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?
What do you all think are the "good bits" of lisp that Clojure lacks?
Not intended as a knock on Clojure, btw, but the JVM is somewhat limiting, in the same way you can't do a "proper" common lisp on the CLR.
[1] http://shenlanguage.org/Hm, I guess I can't imagine how that would work, one language running under all those environments?
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)))
#M((1 2 3 4 5 6 7 8 9 10) #Fun<lfe_eval.12.88887576>)
And using Elixir based things like Phoenix springs to mind...
(lc ((<- x (lists:seq 1 10))) (lfe_io:format "~p" x))
What are limitations?
If you're on a VM or other target that doesn't do them natively, it's worth fighting tooth and nail to somehow get the functionality.
E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list.
But surely one could call a function with one argument, which is a variable-length list of arguments, right?
[] The macro handling can go part way to hide this.
I had to laugh :-) That reads like it's out of the Moonual ...
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.
How do I go about sponsoring a technical writer to complete them?
- Clojure vs LFE
- JVM vs BEAM
- Lisp-1 vs Lisp-2
Etc, if you are interested only in the syntax differences, there is not much difference there (there are obviously some though!). I think generally speaking Erlang has fewer libraries than Java so that is a big difference in my opinion.
Im going to buy some spare paren keys, they might become scarce in the immediate future.
The amount of people who actually use true distributed Erlang is probably small, because you get many of the benefits either way.
This would hurt interop with Erlang, which seems to be a goal of LFE.
As you already wrote in another comment, most practical uses of variadic functions can be replaced by macros.
What remains that is worth fighting the platform for?
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.
> (lists:map (lambda (a) (io:format (integer_to_list a))) (lists:seq 1 10))
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") $ brew install erlang
$ git clone ...lfe.git
$ cd lfe; make && make install
$ lfe
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]))
In Lisp dialects, that is done by a variadic function:
(list 1 2 3 4 ...)
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.
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.
(defmacro foo args
(do 'something (with args)))
(and (>= (length args) 0)
(=< (length args) 255))
Edit: Oops, Robert mentioned this, too.
Even syntaxes which have OAIPA can (and do) still have optional parentheses to exactly delimit the arguments of a call, and that notation can clearly support variadic args.
Outside of explicit delimiting with parens, OAIPA can work on a variadic function up to its required arguments by considering it to be a function of exactly that number of arguments, and no more.
https://groups.google.com/forum/#!msg/comp.lang.lisp/CZX6uGN...
Then LispWorks was fully ported to Mac OS X (incl. Cocoa-based GUI and IDE) and there was then a replacement for Macintosh Common Lisp, which was given up and not ported to OSX/x86/Cocoa.
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.
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 :-)
http://homepage.stat.uiowa.edu/~luke/xls/xlispstat/other/CL/