
The Egison Programming Language - afshinmeh
https://www.egison.org/
======
vosper
> Egison is a programming language that realizes non-linear pattern-matching
> against non-free data types.

It's a what? Can someone ELI5 this for a lowly Python and JS dev - why would I
want this?

\----

I watched a talk about Scala's future [0] recently, in which the presenter
compared the taglines of a few different languages (Go, Rust, Erlang, Scala),
and how they relate to business pains or non-academic problems.

His conclusion about Scala's tagline - "Scala combines object-oriented and
functional programming in one concise, high-level language" is that "no
engineering manager in the history of software development ever thought to
themselves 'hmmm, if only I had a language that fused OO and FP, I'd be able
to solve my business problems'. That hasn't happened; that will never happen.
This is an academic novelty that has zero relevance to any of us as
professional software developers [...] this is not a business pain, this is an
academic interest."

I felt a little bit like that when I read Egison's tagline: why should I care
about this language?

[0] "The Last Hope for Scala's Infinity War"
[https://youtu.be/v8IQ-X2HkGE?t=15m8s](https://youtu.be/v8IQ-X2HkGE?t=15m8s)

~~~
lliamander
Scala's mistake is ostensibly that it is an academic language trying to pitch
itself as a language for building business applications.

Egison appears to be a self-consciously academic language, which strikes me as
a perfectly legitimate.

In particular, the goal seems to be to provide a more intuitive way of writing
algorithms using extensible pattern matching. Now, I have worked on commercial
software that has highly algorithmic parts (graph traversals, etc.) written in
Erlang (a language that supports a powerful, but not extensible, form of
pattern matching). I found the pattern matching facilities to be quite helpful
in producing readable, concise, correct code.

The use case is narrow, but strikes me as real nonetheless.

~~~
vvillena
As a Scala dev, one issue I see with the language is that it doesn't keep you
in check. Easy things are easy and there are lots of syntax sugar and little
conveniences here and there that make the language great, but the advanced
features are just as accesible to the developer. You need self-restraint when
doing Scala, there is a real risk of losing perspective and getting distracted
with fancy features and libraries.

~~~
egi
Which syntax sugar do you think verbose? I don't think Egison has lots of
syntax sugar.

Egison features a customizable pattern-matching facility. Pattern-matching
methods for each data type and pattern can be customizable by users. There
might be a possibility that you thought syntax sugar is not syntax sugar.

------
nerdponx
_Express Intuition Directly with Essentially New Syntax_

 _Egison makes programming dramatically simple!_

    
    
        (define $twin-primes
          (match-all primes (list integer)
            [<join _ <cons $p <cons ,(+ p 2) _>>>
             [p (+ p 2)]]))
    

Uh, ok?

~~~
phkahler
Yep, that's where I stopped. What I think is going on... Some people think
predominantly in abstraction and don't really care about syntax. As Paul
Graham once said, LISP doesn't really have syntax - you write parse trees
directly. That may be fine for people who have achieved that level/style of
programming, but it's a tiny minority.

Why should I write (+ p 2) when most people think (p+2)? This difference gets
worse with more complex expressions. For the masses (and I mean a lot of very
capable people) this is just garbage. For some it's wonderful. I can't say
it's wrong, just not my thing. Perhaps it's the Blub paradox - I've never had
the LISP epiphany so I can't say. I have had the python epiphany, and it's
quite the opposite of this.

~~~
kbp
> LISP doesn't really have syntax - you write parse trees directly.

Lisp has plenty of syntax, it's just extensible and largely defined in
operators. Commonly used macros like DEFUN, WITH-OPEN-FILE, and LOOP all add
their own syntax to the language; that's what macros are for. When you put
them together, typical Lisp code ends up looking like

    
    
        (defun count-words (filespec)
          (with-open-file (f filespec)
            (loop with counts = (make-hash-table :test 'equal)
                  for line = (read-line f nil)
                  while line do
                    (loop for word in (cl-ppcre:split "\\s+" line) do
                      (incf (gethash word counts 0)))
                  finally (return counts))))
    

Which I don't think is that alien. It translates pretty cleanly into Python:

    
    
        def count_words(filespec):
            with open(filespec) as f:
                counts = collections.defaultdict(int)
                for line in f:
                    for word in line.split():
                        counts[word] += 1
                return counts
    

Do you find the former significantly harder to understand? I don't see how
it's any more like "writing a parse tree directly."

> Why should I write (+ p 2) when most people think (p+2)? This difference
> gets worse with more complex expressions.

As mentioned in other comments, there are infix packages available for when
you're writing math-heavy code (or if you just _need_ infix operators), but I
also think that a lot of people don't write very much code with complicated
inline arithmetic in it, and overstate how much the awkward math syntax would
affect them (there are of course plenty of projects that are math-heavy and
where it does make a large difference). When you're defining
variables/functions/classes/etc or calling functions or looping or whatever,
there's not much difference between Lisp and most other languages aside from
whether the bracket is { or ( and which side of the keyword it goes on; in my
experience, that sort of code tends to make up the large bulk of most
codebases in most languages.

edit: Another place where Lisp's default syntax is significantly different
from a lot of languages is something like object.f(x).g(y).h(z), which in Lisp
looks like (h (g (f object x) y) z). This can be remedied with common macros
like -> that let you write (-> object (f x) (g y) (h z)).

~~~
tigershark
Both your snippets are exceedingly long, verbose and painful to understand. In
C#, that normally is a quite verbose language, you can write just this:

    
    
        IDictionary<string, int> CountWords(string f) => File.ReadAllText(f).Split().ToLookup(w => w).ToDictionary(kv => kv.Key, kv => kv.Count());
    

Or a bit more concise in F#:

    
    
        let wordsCount f = File.ReadAllText(f).Split() |> Array.groupBy id |> Array.map (fun x |> fst x, (snd x).Length) |> dict

~~~
kbp
Sure, there's other ways to write it, the point of the post was Lisp's syntax,
not the algorithm I used to demonstrate some features of it. You could write
examples like yours in Lisp or Python, too. As well, your examples both slurp
the whole file into memory, which mine avoided.

edit: And your C# version is only 24 non-whitespace characters shorter than
the Python version, and 20 of those are because you called your variables 'f'
instead of 'filespec' and 'w' instead of 'word'. A 4 non-whitespace character
difference makes it exceedingly long and verbose? Or are you just advocating
1-letter variable names and avoiding newlines?

~~~
tigershark
The c# version is calling only 4 methods and in C# you obviously have to
declare the types. It’s the difference between declarative style versus
imperative that I wanted to highlight, obviously Python is more compact than
C#, but written in that way it becomes more verbose and more difficult to read
and write. Write something like that in Lisp and let’s see how it compares.

~~~
kazinator
Isn't "kv => kv.Key" a lambda function that is called?

------
chenglou
I’ve been casually following Egison for a while now. Its customizable pattern
matching is really cool. Unfortunately I do think the lisp syntax does turn
some folks off; whether this set of folks overlaps with those who would be
interested in Egison otherwise, is another question.

I’ve also noticed that it “pivoted” to focus more on math; is that
intentional?

Anyway, good to see it on HN again. Anything that pushes more pattern matching
research is a plus for me =). Mainstream languages barely started to adopt
first-order pattern matching!

~~~
egi
Thank you for your comment!

I started to implement a computer algebra system as a killer application of
customizable pattern matching of Egison.

It allows users to customize the pattern-method for mathematical expressions
from more primitive level than the other computer algebra systems.

------
mapcars
Looks like a lisp dialect, why is it a separate language?

~~~
ketralnis
A language is a dialect with an army and a-- err a parser and a compiler :)

------
amckinlay
This looks like an intruiging alternative to Julia. Last time I tried Julia,
effecient multidimensional code generation was incomplete due to required work
in the type system. I wonder how Egison's performance matches it's
expressiveness.

~~~
eigenspace
When did you last try julia? Things are looking pretty great these days.

------
bcheung
I love how it matches so much more. It would take me some time wrap my head
around the new possibilities.

I doubt I have time to learn this or use it but it would be cool to see a list
of examples of things that are much more concise and elegant in this language
so that it expands my thinking. Is there a list of examples with comparisons
to traditional languages?

------
nikofeyn
interesting about the math integration with tensors and differential forms.
gonna have to read the linked paper.

~~~
egi
Thank you for your interest!

Here is a link for a new paper that discusses the integration of tensor index
notation including the support for differential forms.

[https://arxiv.org/abs/1804.03140](https://arxiv.org/abs/1804.03140)

~~~
carapace
This seems very interesting, I have only just skimmed it so far. Am I wrong in
thinking this might relate to (representations for) Geometric Algebra?

~~~
egi
The calculus for differential forms is a part of Geometric algebra, so I think
there is a relation. Egison's strong point is it can handle tensor-valued
p-forms due to its ability to handle both of tensor index notation and
differential forms at the same time.

~~~
carapace
Cheers.

------
kamyarg
Your syntax is bad and you should feel bad.

Mandatory XKCD: [https://xkcd.com/297/](https://xkcd.com/297/)

------
Pica_soO
Is there a academic language which focuses solely on performance and
optimization- by building the program and data structures around the hot-loop
and optimal cache usage? Something Mike Acton would create if he wrote
compilers?

~~~
carapace
A language called "Spiral" went by yesterday, that I think does a little bit
of that.
[https://news.ycombinator.com/item?id=17519138](https://news.ycombinator.com/item?id=17519138)

