Hacker News new | past | comments | ask | show | jobs | submit login
Egison – Pattern-matching-oriented Programming Language (egison.org)
70 points by hamidr on July 5, 2014 | hide | past | web | favorite | 33 comments



The creator of the language here, ask me anything. Please check my paper recently I put on arXiv.org. http://arxiv.org/abs/1407.0729


This looks super interesting, thanks for including so many demos and docs. I'm pretty new to PL theory, but was recently reading about OMeta - another "language for pattern matching". For example, here's a png parser in OMeta.[1]

Maybe you could help me understand how Egison compares to OMeta? thanks.

1. http://www.joshondesign.com/2013/03/18/ConciseComputing


I read a slide on OMeta. http://tinlizzie.org/ometa/dls07-slides.pdf Its pattern matching is specialized in expressing pattern matching against lists and trees. Egison aims intuitive expression for a wider range of data types and provide non-linear pattern matching with multiple results on a functional language. Please check a cheat sheet and demo pages on our website. We can get its concepts easily from them. http://www.egison.org/cheatsheet.html http://www.egison.org/demonstrations/poker-hands.html


Thanks. It looks to me like Egison is focused on pattern matching of data. While OMeta is focused on pattern matching of syntax (so is used to create and extend new languages/DSLs). Is that a fair comparison?

How does the Egison online evaluator work? Server-side haskell or the ruby extension?

Any plans for a javascript extension?


What you wrote is what I wanted to write. We call the Egison command on the server limiting code with side-effects via an API server implemeted in Ruby. All source code on Egison including its website is on GitHub. Please check them, too. https://github.com/egison I’m not planning a javascript extension for now, though I’d like it.


Oh, your markdown-editor looks really shiny... have you since given up working with ometa? For some reason it never occurred to me that ometajs and nodejs might be a great match until I read your (entirely client side) stuff ... I guess I just needed the right context to make the connection.

The more I think about it, the ability to create ones own language and execute on the server or on the client as one sees fit, seems like a really nice match. And all without having to do something "heavy handed" like clojurescript or other "overt" compile-to-js stuff...

Hm, and here I thought I'd given up on nodejs, and was ready to move on to other server side languages ;-)

Writing a custom markdown DSL that can live-preview in the editing client, and render to static html on the server for high volume, low-overhead hosting sounds kind of appealing... (There are of course many ways to do this, but the idea of a single, concise grammar and rendering engine is very appealing....).


> Oh, your markdown-editor looks really shiny... have you since given up working with ometa?

That's not me, its somebody else's blog. I only discovered ometa a couple months ago. I'm looking forward to trying it for a project soon, but the documentation I've found is pretty scattered. Here's a decent tutorial though: https://github.com/rulemotion/ometa-tuts/blob/master/tut1.md


Thanks for that. Yes, I'm a little sad a lot of the VRI stuff has a bit of "abandonware" feel -- I suppose they view it at just some (half-silly) proof-of-concept code, but I think a lot of this stuff could be really useful right now.

I really wish they'd taken the time to package it up, and license it under some Free licence -- I'd hate for this stuff that doesn't seem to require anything in the way of special hardware -- languish and disappear in a similar way to Smalltalk -- for no good reason.


There was a previous thread about egison[0]. Several of us were curious as to why you created an entirely new language. Can't the kind of pattern matching egision provides be implemented in some other Lisp through macros?

[0] https://news.ycombinator.com/item?id=7924168


At first, I tried to extend the existing language. However, it was difficult because implementation of the Egison pattern-matching has big influence for whole design of a programming language. I wrote answers for this question and other frequently asked questions on our website. Please check it too. http://www.egison.org/faq.html#why-new-language


Very interesting!

By the way, I noticed a typo in the cheat sheet:

> The primes is a collection that contains all natural numbers.


Thanks! I've fixed that just now.


Love the 'cheat sheet' accessible from the landing page. Great way to give a feeling of what it's like in under a minute.


Because lispy syntax is alien to me, how is this different to the pattern matching of other languages (I barely know the ones about Haskell, and now swift)?

This interest me because I'm dreaming about build a language and think pattern matching is very cool and look like can replace if & case.


The biggest difference is Egison realizes non-linear pattern matching against unfree data types such as multisets and sets. I've wrote brief comparison here. https://github.com/egison/egison#comparison-with-related-wor... Please check my paper, too. http://arxiv.org/abs/1407.0729


Ok, which are the baby steps to implement pattern matching in a language?, and if is more similar to python/swift than lisp?


I'm sorry but I think if you would like to implement a language not only use it, it would be better to learn lisp at first. It is very easy to implement lisp on lisp and modify it as you like. This is an scheme interpreter I wrote in scheme. It's extremely short compared with other language. There are many good textbooks, too. http://www.scheme.com/tspl4/


I understand that a lispy language make some stuff about building a language easier, but still is very common to use a imperative one to build them, and in imperatives I'm skilled...

So the question are really 2, to make them more clear:

1- What are the baby steps to make pattern matching?

I could follow a functional language if the explanation is clear, but if the code requiere skills in them I could get lost. So, I ask if exist this kind of resource, if possible. If not, then anything else is ok and them I know I need to devote some time in learn other kind of skills.

2- Is pattern matching more problematic if the language is not functional, inmutable? If is a mix (like with swift), what is the sweet spot (if exist?) or what is needed to make it work easily/better?. So for example, lets imagine that if the language is not statically typed it become harder to implement..


I wrote my answer.

1- I'm sorry but I don't know materials for the baby steps to implement pattern matching. However, I think it is not so difficult to compile ordinary pattern matching expression into many nested if expressions, if you have a small language you can manage completely.

2- I think difficulty to implement a pattern matching mechanism is not different for each language. I think writing a parser may be the hardest work.

By the way, I forgot to paste URL for my interpreter I wrote in the past. https://github.com/egisatoshi/scheme-meta-interpreter/blob/m... Lisp is easy to write a parser, and it's because I recommended lisp.


Could this finally be a real replacement for Snobol?


Egison looks interesting, but I think maybe Ometa is closer to being a Snobol-replacement than Egison -- at least for now.

On a side note, I came across this: https://github.com/daveshields/gospitbol


Why do you think so? I've created Egison not for text processing, but I think text processing is important application of pattern matching and I'd like to do work for that in future.


Perhaps Egison might be a useful tool for building a snobol replacement, or perhaps I personally just don't find the syntax to be quite so amendable to ad-hoc text processing. I could very well be wrong, though. As I said up-thread -- it's a very interesting project :-)


Does Egison implement the Pattern Calculus?

http://en.wikipedia.org/wiki/Pattern_calculus


No. I don't refer to the Pattern Calculus when I've implemented Egison. I've implemented Egison to realize non-linear pattern matching against unfree data types such as sets and multisets. The Pattern Calculus seems not for that.


Amazing work nonetheless, I'm looking at slide 50 now. Very interesting concept.

I had to google "unfree data types". This seems to refer to data types that are unstructured and therefore no one thought of a way to represent in syntax. For instance we can ask if the first item of a list (a structured data type) is equal to the last, but we do not have good syntax (nor semantics) to ask what are the pairs that occur in a collection. That's why we keep having to translate between those structures in order to do some operations or ask certain questions.

Very cool stuff.


I believe Egison has provided good syntax and semantics for that. We have demonstration pages of various Egison programs that you can edit and run online. Please check them too. http://www.egison.org/demonstrations/poker-hands.html


is it compilable? is there a windowing library? roughly what is the speed comparable to? the examples look very nice, gj


Thank you. We are providing only an interpreter now. Egison is not fast and we don't provide benchmark yet. The development of Egison is currently sponsored by Rakuten and Rakuten Institute of Technology, but a current active developer is only me.


Is there some way to break computation? I had a look at the tutorial, and went from: (take 10 nats) via (take 1 (reverse (take 1000 nats))) to doing the same with 10000000 (or so). ctrl-z and pkill let me go on to to other things, but it would've been nice if ctrl-c worked as well...?


If you install egison on your machine, ctrl-c should work on your machine. However, ctrl-c does not work online egison currently.


Hm, you're right -- could be that cpu/swappiness was the issue. If instantiate less from the lazy sequence, I can indeed break with ctrl-c, so eg: 30000 is about enough not to eat all resources, and still take enough time that I can ctrl-c--out (and also does complete without crashing if I let it run a little while, about a second I think):

    (take 1 (reverse (take 30000 nats)))
Anyone know if this is a known issue with Haskell (I assuming this is a pretty straight wrap for Haskell lazy lists?) -- that you can get the compiler/runtime into a tight loop eating so many resources that it isn't possible to abort cleanly?


Thank you for letting me to know about this issue. I noticed this problem for the first time. Our implementation of lazy evaluation is not straight wrap of Haskell. I'll look into about this.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: