Egison – Pattern-matching-oriented Programming Language
egison.org
egison.org
Maybe you could help me understand how Egison compares to OMeta? thanks.
How does the Egison online evaluator work? Server-side haskell or the ruby extension?
Any plans for a javascript extension?
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....).
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
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.
By the way, I noticed a typo in the cheat sheet:
> The primes is a collection that contains all natural numbers.
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.
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.
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.
On a side note, I came across this: https://github.com/daveshields/gospitbol
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.
(take 1 (reverse (take 30000 nats)))