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.
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?
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?
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
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.
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..
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.
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 :-)
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.
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
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...?
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.
