LFE or EFL?

[TR NS]

Today I was wondering if the world really needed yet another Lisp. Lisp has tried so many times to get off the ground and has never quite been able to get there. Presently Clojure seems the "best great hope" for Lisp, but I doubt it will ever really get huge. And if we are being honest, Clojure has a bit more going for it than LFE.

So I was thinking maybe LFE would be better off it stopped trying to be an EFL -- Erlang flavored Lisp, and really turn a corner to become something more than Lisp -- to really embrace its name LFE as an Erlang first, but with a Lisp style.

What do I mean by this? Well one example is to consider function definitions. LFE just has your old-school list style functions, taking a list of parameters. But Erlang's functions are full-on pattern-matches.

So for example, instead of something like:

    (defun foo (message)
      (let (((tuple len status data) message))
       ...))

Just go for it with:

    (defun foo {len status data}
       ...)

Going further, in Erlang all variables start with a capital letter, so it can use unadorned atoms for pattern matching. That's a pretty nice feature. Lisp requires a prefix, like an apostrophe. Lets embrace the Erlang,

    (defun Area {square Length Height}
       (* Length Height))

    (Area square 10 10)

Consider another example, using Erlang H | T notation,
     

    (defun Tally ({Quantity Product} | T)
       (+ Quantity (Tally T))

    (Tally {10 apples} {2 pies} {3 soups})

So in short, instead of just being another Lisp with Erlang underpinnings, maybe it would be better to embrace the Erlang and put a really sexy Lisp-esque dress on her.

Just a thought.

[Eric Bailey]

On Oct 16, 2016, at 10:49 PM, TR NS <tran...@gmail.com> wrote:

Today I was wondering if the world really needed yet another Lisp. Lisp has tried so many times to get off the ground and has never quite been able to get there. Presently Clojure seems the "best great hope" for Lisp, but I doubt it will ever really get huge. And if we are being honest, Clojure has a bit more going for it than LFE.

So I was thinking maybe LFE would be better off it stopped trying to be an EFL -- Erlang flavored Lisp, and really turn a corner to become something more than Lisp -- to really embrace its name LFE as an Erlang first, but with a Lisp style.

What do I mean by this? Well one example is to consider function definitions. LFE just has your old-school list style functions, taking a list of parameters. But Erlang's functions are full-on pattern-matches.

So for example, instead of something like:

    (defun foo (message)
      (let (((tuple len status data) message))
       ...))

Just go for it with:

    (defun foo {len status data}
       …)

We already support such pattern matching using function clauses like this:

(defun foo

  ([(= (tuple len status data) message)]

   …))

or in an anonymous function like this:

(match-lambda

  ([(= (tuple len status data) message)]

   ...))

Going further, in Erlang all variables start with a capital letter, so it can use unadorned atoms for pattern matching. That's a pretty nice feature. Lisp requires a prefix, like an apostrophe. Lets embrace the Erlang,

    (defun Area {square Length Height}
       (* Length Height))

    (Area square 10 10

I don’t follow this example. Is square supposed to be a record? If so, we can do this:

> (defrecord square length height)

set-square-height

> (defun area

>   ([(match-square length length height height)]

>    (* length height)))

area

> (area (make-square length 10 height 10))

100

If it’s supposed to be the atom ‘square, then we can do:

> (defun area

>   (['square length height]

>    (* length height)))

area

> (area 'square 10 10)

100

Consider another example, using Erlang H | T notation,
     

    (defun Tally ({Quantity Product} | T)
       (+ Quantity (Tally T))

    (Tally {10 apples} {2 pies} {3 soups})

I don’t follow this example either. I’m assuming you mean something like this:

> (defun tally

>   ([()] 0)

>   ([`(#(,quantity ,_product) . ,t)]

>    (+ quantity (tally t))))

tally

> (tally '[#(10 apples) #(2 pies) #(3 soups)])

15

So in short, instead of just being another Lisp with Erlang underpinnings, maybe it would be better to embrace the Erlang and put a really sexy Lisp-esque dress on her.

Just a thought.

--
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 https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Torbjörn Törnkvist]

The LFE examples below looks awkward to me.

I like Lisp but I also like much of the Erlang syntax.

So what does LFE bring to the table that I don't get with Erlang?

Things that I would consider a big plus (i.e things that are annoying in Erlang):

1. Prohibit export of variables from case/if expressions.

2. Support the all too common/silly pattern of binding a new temporary variable (A = ..., A1 = ...something with A..., A2 = ...something with A1...)

3. Enforce a more functional programming style to avoid lengthy code in a clause.

4. An even cleaner syntax (is that possible?)

The first three points above are something you can deal with in Erlang if you know how

and have some discipline. But it is very common to see the opposite in any Erlang code base.

Idea: Why does a 'new' beam-language need to deal with processes?

Why not let that part of the code exist in Erlang libraries and instead deal with

sequential code, which is the major part of any code base anyway.

Non-Lisp example playing around with point 4:  https://github.com/etnt/eml

Cheers, Tobbe

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.

Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
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-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

[TR NS]

On Monday, October 17, 2016 at 5:14:18 PM UTC-4, Eric Bailey wrote:

On Oct 16, 2016, at 10:49 PM, TR NS <tran...@gmail.com> wrote:

Today I was wondering if the world really needed yet another Lisp. Lisp has tried so many times to get off the ground and has never quite been able to get there. Presently Clojure seems the "best great hope" for Lisp, but I doubt it will ever really get huge. And if we are being honest, Clojure has a bit more going for it than LFE.

So I was thinking maybe LFE would be better off it stopped trying to be an EFL -- Erlang flavored Lisp, and really turn a corner to become something more than Lisp -- to really embrace its name LFE as an Erlang first, but with a Lisp style.

What do I mean by this? Well one example is to consider function definitions. LFE just has your old-school list style functions, taking a list of parameters. But Erlang's functions are full-on pattern-matches.

So for example, instead of something like:

    (defun foo (message)
      (let (((tuple len status data) message))
       ...))

Just go for it with:

    (defun foo {len status data}
       …)

We already support such pattern matching using function clauses like this:

(defun foo

  ([(= (tuple len status data) message)]

   …))

or in an anonymous function like this:

(match-lambda

  ([(= (tuple len status data) message)]

   ...))

( ( [ ( ( ) ) ] ) )

vs

( { } )
 

Going further, in Erlang all variables start with a capital letter, so it can use unadorned atoms for pattern matching. That's a pretty nice feature. Lisp requires a prefix, like an apostrophe. Lets embrace the Erlang,

    (defun Area {square Length Height}
       (* Length Height))

    (Area square 10 10)

I don’t follow this example. Is square supposed to be a record? If so, we can do this:

It's a tuple, b/c { } are tuples in Erlang.
 

> (defrecord square length height)

set-square-height

> (defun area

>   ([(match-square length length height height)]

>    (* length height)))

area

> (area (make-square length 10 height 10))

100

If it’s supposed to be the atom ‘square, then we can do:

> (defun area

>   (['square length height]

>    (* length height)))

area

> (area 'square 10 10)

100

You are really missing my point. But again see my first comment.
 

Consider another example, using Erlang H | T notation,
     

    (defun Tally ({Quantity Product} | T)
       (+ Quantity (Tally T))

    (Tally {10 apples} {2 pies} {3 soups})

I don’t follow this example either. I’m assuming you mean something like this:

> (defun tally

>   ([()] 0)

>   ([`(#(,quantity ,_product) . ,t)]

>    (+ quantity (tally t))))

tally

> (tally '[#(10 apples) #(2 pies) #(3 soups)])

15

Compare those two examples objectively. Which would you really want to try to decipher day in and day out?
 
Anyway, I understand some people are heavily invested in Lisp as it is, so LFE gives them an outlet on the BEAM and use of Erlangs libraries. I'm just in another camp, that would like to see significant innovations for a change -- Lisp, the Next Generation and not just Lisp, the Continuing Mission.

[Michael Forster]

On Wed, Oct 19, 2016 at 4:31 AM, TR NS <tran...@gmail.com> wrote:
>
>

[...]

>
> ( ( [ ( ( ) ) ] ) )
>
> vs
>
> ( { } )
>

[... and separately ...]

> Compare those two examples objectively. Which would you really want to try
> to decipher day in and day out?
>
> Anyway, I understand some people are heavily invested in Lisp as it is, so
> LFE gives them an outlet on the BEAM and use of Erlangs libraries. I'm just
> in another camp, that would like to see significant innovations for a change
> -- Lisp, the Next Generation and not just Lisp, the Continuing Mission.

Hi,

Both of the comparisons above make assumptions about Lisp and the
intentions of its long history of proponents: that Lisp's syntax is
its surface syntax, and that it's proponents must be mad to not employ
a wider assortment of read-time symbols for sake of a more concise
surface syntax.

At the risk of sounding like an ass, I'll paraphrase Spoon Boy:

Do not try and change the Lisp syntax, that's impossible.
Instead, only try to realize the truth...there is no Lisp syntax.
Then you will see it is not the Lisp that bends, it is only yourself.

Of course, there is a Lisp syntax, but it's not meant to be the
surface syntax; it's meant to be the substrate upon which you build
_your_ syntax or, better, the syntax for problem at hand. What looks
to you, a human, to be a gratuitous number and nesting of parenthesis
is just the minimal number of dispatch symbols and expression
delimiters necessary:

1) to evaluate Lisp expressions unambiguously; and

2) to allow you to generate such expressions mechanically with macros.

This issue has been raised, in one form or another, since the original
debate over s- and m-expressions. I misunderstood this 20 years ago,
and it didn't sink in until talking with several seasoned Lispers and
reading a lot of big Lisp sources. Even this oft-posted graphic belies
the real point:

https://web.archive.org/web/20110125011148/http://img264.imageshack.us/img264/1397/lispnd7.png

My point is that there can be only "Lisp, the Continuing Mission," but
that mission is to give you the simplest machinery for _you_ to
innovate on top--the programmable programming language. If you just
want a more concise syntax, suited to human rather than macro
consumption, you don't want Lisp. Maybe you want Elixir.


Best regards,

Mike

[Robert Virding]

A quick comment to Mike's comments:

Yes, the thing to remember is the homoiconcity of lispand that you are really just writing down a data structure which is *interpreted* as code. This is what makes lisp's macro facility so powerful.

Also the Elixir syntax, while it may feel comfortable to many, is actually quite complex and you can run into problems if you arenot careful.

I am travelling at the moment and will come with a longer comment later.

Robert

[TR NS]

On Wednesday, October 19, 2016 at 8:18:53 AM UTC-4, Michael Forster wrote:

At the risk of sounding like an ass, I'll paraphrase Spoon Boy:

    Do not try and change the Lisp syntax, that's impossible.
    Instead, only try to realize the truth...there is no Lisp syntax.
    Then you will see it is not the Lisp that bends, it is only yourself.

Oh, please.
 

My point is that there can be only "Lisp, the Continuing Mission," but
that mission is to give you the simplest machinery for _you_ to
innovate on top--the programmable programming language. If you just
want a more concise syntax, suited to human rather than macro
consumption, you don't want Lisp. Maybe you want Elixir.

Sorry, I just flat out disagree.

I don't see Elixir particularly representative of an improvement.

[Mason Staugler]

LFE's point is to be a Lisp, so I think it's a little strange to be upset at how much it's like a Lisp. I don't think Java should become less like Java; I think Java's wrong and acting less like Java just makes it wronger. Also, the Java community doesn't care what I think about Java.

I don't have any experience with Lisp besides LFE. When I started, I found the pattern matching form of defun to be incredibly confusing. After working with it a little bit, I don't even think about it anymore -- it makes sense! (Incidentally, I read people saying that when I started out and thought it was bunk and played around with different ways of representing it.)

I think your premises are flawed if you think there's a syntax problem with both Erlang and LFE. I came to LFE to get away from Erlang syntax but instead have grown to like them both *a lot*.

There is still a lot of work to be done with LFE but it's absolutely on the right track.

[mi...@forsterfamily.ca]

On Wednesday, October 19, 2016 at 8:58:33 PM UTC-5, Mason Staugler wrote:

[...]

I don't have any experience with Lisp besides LFE. When I started, I found the pattern matching form of defun to be incredibly confusing. After working with it a little bit, I don't even think about it anymore -- it makes sense! (Incidentally, I read people saying that when I started out and thought it was bunk and played around with different ways of representing it.)

[...]

Indeed, Robert's approach to incorporating Erlang pattern matching yields exactly what you'd expect--and want--with a Lisp. Compare with pattern matching in Common Lisp [1] and Racket [2]. All three are straightforward to learn and, once learned, quick to work with.

[1] https://github.com/m2ym/optima
[2] http://docs.racket-lang.org/reference/match.html

[Eric Bailey]

Thanks, I better understand your points now, TR NS (not sure of your name), but tend to side with Michael and Robert, if we're choosing sides. You mentioned objectivity and I have anything but, having been involved with LFE on some level for a couple years now. I've got a similar atttitide to Mason at this point.

A couple of my favorite features of LFE are its simplicity/minimalism and explicitness. While sometimes that gets a little wordy or parentheses-y, in the end I think I prefer it to the proposed alternatives, yours and the many others.

I forget who it was now, but someone said they had a higher-level DSL that generated LFE (among other languages). That sounds compelling to me for those who don't like the syntax. The LFE compiler itself basically takes more human-friendly code and generates an internal representation of sorts. Going another level up seems feasible, if not smart.

I know James (dysfun on IRC and jjl or jpl on GitHub) was once working on a swappable frontend for the compiler to support more Clojurian syntax, as well as arbitrary syntaxes. Perhaps that's a good way forward.

Given the general experience seems to be something like "learn the LFE syntax once, then embrace and forget about it thereafter," I think we really ought to focus our efforts on documentation. In another thread there's the beginning of a roadmap to that end.

Thanks for your feedback, everyone. These discussions are important, even (or maybe especially) when we don't agree.

Eric

[Robert Virding]

Getting in a bit late into this discussion. As most probably guess I rather like the traditional lisp syntax :-).

TR NS I have some comments on your original suggestions:

- The classic lisp syntax is very simple and consistent: all the basic constructs are lists where the first element says how the list is to be interpreted. It doesn't have infix/postfix operators. And it is homoiconic. This makes things very simple and makes macros very powerful and easy to use. I honestly don't see any reason to change this and add operators.

- Most languages with pattern matching, those I know anyway, the syntax of a pattern is the same as the syntax of constructors. This makes things very consistent and easy to understand.

- Your syntax for functions does not naturally extend to functions with multiple arguments, which is severely limiting. Pattern matching is not just used for pulling things apart but for testing structure and control of flow in programs, same in LFE. So in most functions where you pattern match the arguments you have different alternatives depending on the structure of the arguments, clauses in Erlang and LFE. Your syntax does not naturally support this.

- Yes, LFE was designed to be a classic lisp. At least as close as possible given the properties of the BEAM, the Erlang VM. It was also designed to interact seamlessly with Erlang and OTP. This clearly affected the design of the language and many of its features have been defined according to this, for example module structure.

LFE is not finished and work on it continues. New features are coming and the number of libraries keeps increasing. Anyone is free to help if they wish.

I personally like languages with simple consistent syntax as they are much easier to extend and build on. Complexity just makes things difficult in the long run. Consistency is also a big win as it makes things easier to understand. If you look at the Erlang syntax you will also see that it is also simple and consistent, much more than the syntax of languages that its detractors think it should look like.

These are some of my thoughts on language design which have gone into the design of LFE and explain why I like lisp. It took a while until I got an Erlang with lisp syntax. :-)

Robert

P.S. It has always been called LFE, Lisp Flavoured Erlang, but considering how much it has grown from its beginning a better name would probably be EFL, Erlang Flavoured Lisp. No, I am not going to change its name. :-)