A toy Mathematica interpreter in Haskell | Hacker News Reader

A toy Mathematica interpreter in Haskell

community.wolfram.com

191 pointssoofy50 comments

Mathics is implementation of Mathematica (actually it is now called Wolfram language) using sympy, ply, and django.

It also provides jupyter kernel.

The original author was hired by Wolfram, but the project still lives on!

http://mathics.github.io

Maxima is older than Mathematica and written in LISP. One of its contributors has written MockMMA to implement Mathematica in LISP:

https://people.eecs.berkeley.edu/~fateman/lisp/

I've looked at the github project for Mathics and didn't see any use of ply... Looks like they have written their own parser/lexer.

Yes, indeed - it is very weird! Because mathics still mentions ply in change.rst, but not used in code anymore:

https://github.com/mathics/Mathics/blob/master/CHANGES.rst

Hidden in there (under 1.0) is "new recursive descent parser #416". We've only just finished 1.0 and haven't had a chance to announce it properly yet.

is this limitation in ply?

We previously used ply but ran into a few issues:

The main issue was that generating the tables was extremely slow (~15mins). We solved this by packaging the tables, but when the version of ply changed a table regeneration was forced on our users.

The recursive descent parser was also simpler and significantly more performant.

There's a short write-up on the PR: https://github.com/mathics/Mathics/pull/416

Mathics developer here. Yes, we rewrote it. I better update the docs.

I've written a Mathematica clone twice before. This guy got there much faster ( I was writing in C++).

However both times I got the basic language going then realized it was the standard library that made Mathematica gold and abandoned it.

Kudos to him and it's good work!

The library is really impressive. I wanted to do some feedback linearization of a system and started encoding the dynamics into Mathematica. I got about halfway done doing it on my own when I discovered there was a built in to do it for me.

Mathematica's value is in the library, not the language. Wolfram etc put a ton of effort into making it do a good job on arbitrary problems. See the Mathematica book for me detail- for example, the root finding stuff is really neat.

Are the solver algorithms part of the standard library or part of the execution engine? i.e., are Solve/DSolve/etc. written in plain Mathematica code, or are they special somehow?

You can call external code from Mathematica, so they can be part of the standard lib and be special.

OK, but that doesn't answer my question...

This is a great question. I suspect they use hard-coded stuff deep in the math kernel for efficiency. I remember the Mathematica book goes into detail on this, but I don't recall the specifics.

This proves, once again, what a world-class, unbeatable tool Haskell is for writing toy interpreters.

Any ML language is.

When I was at the university[0], we were forbidden to use Caml Light, Lisp or Prolog in our compiler classes, because they would make the exercises too easy and so we wouldn't learn properly.

[0] Haskell was still to be born and we had Miranda instead.

You might want to read his comment a little more carefully

> unbeatable tool Haskell is for writing toy interpreters.

unbeatable

As if no other language has the same feature set.

bertiewhykovich wasn't actually praising Haskell.

That isn't what I understand, maybe it lies on my lack of English skills.

I am English (and so a natural English speaker) and I read it in the exact same fashion that you did. I think the original poster may have been trying to be sarcastic, (it still isn't clear), but was so subtle about it that they failed for both of us.

Translation: Haskell may be the most heralded language to produce almost no production code.

Well I am aware of several production uses of Haskell in UK, Netherlands and Germany.

Haskell seems to have the most users who usually can't be named, and certainly don't share their code publicly. But trust us, honest, they exist!

Did you ever bothered to check these companies?

https://wiki.haskell.org/Haskell_in_industry

Yes, well, anyone can find that out if they care to. The point is the person you replied to was interpreting the original sarcasm, not trying to make a factual statement.

As non native English speaker I didn't get it was any kind of sarcasm.

I know, which is why I replied to your comment ;-)

focus your eye on the word TOY and think about it for a while

So explain me why Lisp, Prolog or any ML derivative aren't as capable as Haskell for TOY interpreters.

Unless s/he was being sarcastic, but if so I don't get the joke.

Prepare for a facepalm.

It has nothing to do with Lisp or ML.

Read again:

> This proves, once again, what a world-class, unbeatable tool Haskell is for writing toy interpreters.

This somehow suggest a) that it is not quite exactly really there, where one may want to develop a non-toy interpreter/compiler/... and/or b) that a lot of examples are just toy programs which can be as well developed in any language and one has now seen zillions of those in Haskell and everyone is convinced that Haskell is good for implementing toy interpreters. and/or c) that the quality of the code stays on toy level.

In this case it is a slightly more advanced toy interpreter, but the implementation lacks any information about its architecture, there is no documentation, stuff is hardcoded, etc. It's the typical slightly autistic implementation where there is the code and a some tests...

The real challenge would be to develop a non-toy interpreter/compiler/... Is there Haskell still a world-class, unbeatable tool?

Personally I'm not a Haskell user, but I like that people are writing code in it. Though for such an application I would like to see a bit more effort on the meta-information about the code. You can see that in some (!) Lisp programs, people invest some effort to make them very expressive and readable. Just read the PAIP code/book from Peter Norvig which implements some parts of Macsyma in Common Lisp.

But there is the danger of not being able to really compete for many high-level languages. Lisp had some attempts for actual products in this domain of computer algebra: Macsyma, Reduce and Axiom were the most prominent. The were developed as real products with actual end-users. They failed in the market place against languages with C/C++-based implementations like Mathematica. Though they are still being maintained as open source / free software projects.

Thanks for taking the effort of writing it down.

Still, I don't agree with the snarky remark of the OP, hence why I wasn't getting it, as there are several uses of Haskell in production.

Besides Microsoft, Facebook and Intel there are quite a few other companies using it in production, specially in financial and insurance sector for data modelling.

I am the other way, I have dabbled quite a few times with Lisp languages, mostly Emacs Lisp, Guile and Clojure.

I am also a big fan of the old Lisp Machines, but having learned FP in Caml Light, my brain got hardwired to ML derived languages.

Use in production - often in-house production - is slightly different than development of a non-toy language implementation or a non-toy application (here an interpreter for a clone of the Mathematica language).

Non-toy computer-algebra applications in Lisp were/are Macsyma/Maxima/Vaxima, Reduce and Axiom. They were real products an end user could buy. There is an extensive amount of literature about Macsyma: http://ftp.math.utah.edu/pub/tex/bib/macsyma.bib

But then one might want to survive in the market place.

Btw., people even use the C64 still in 'production'. ;-)

http://sploid.gizmodo.com/this-old-ass-commodore-64-is-still...

Well, here is a non-toy language implementation used by Intel for hardware design implemented in Haskell:

https://www.cs.ox.ac.uk/tom.melham/res/reflect.html

Is it implemented in Haskell and not in C/C++? The papers I saw didn't say anything about the implementation.

I guess it was the one they use for formal verification of their CPUs.

But there is also the Sigma rules engine used at Facebok as another possible example,

https://code.facebook.com/posts/745068642270222/fighting-spa...

Well, that's a rule engine embedded into Haskell. Great, but different from a language implementation of the Mathematica language (syntax / parser, ... , interpreter).

Anyway, that what I said above. Inhouse use for special purpose applications.

It is still production code, with people being paid to write code in Haskell.

That still says nothing about the code.

Just as a note, Norvig switched to Python for nearly all programming. Personally I think this is because nearly any language can do enough interesting things (like implementing an algebra or symbolic math library) but more importantly, far more people want to learn/use Python than lisp.

> far more people want to learn/use Python than lisp.

It's also much simpler than Lisp, without the confusing ideas of 'code as data' and 'programmable programming language'.

is that really true? I guess I never really paid close enough attention to the details, but you can certainly represent code as python data objects.

Well, I mean, I understood the sarcasm and it was funny. Part of why it was so funny is because it's true. Haskell is amazing at many things, and one of them certainly is writing toy interpreters.

Do you know how many problems can be reduced to writing a toy interpreter? You're much too dismissive of a very useful software engineering technique. (That's if you meant your comment as sarcasm; if it's praise then I'd agree.)

I've written a toy TeX interpreter/macro-expander as my first "large" Haskell program. It really made me think hard about both Haskell and TeX. I think this is a great way to learn two languages at the same time if you already have experience.

It would be interesting to benchmark it against the real thing.

doesn't this turn Mathematica into a scripting language for Haskell?

Not any more than CPython is a scripting language for C. The Mathematica program is entirely interpenetrated. It does not have access to the underlying Haskell system.

That's a bit of a shame, in some way. In the same way Hy [0] wraps Lisp's notation style around Python, it would be quite powerful if there was a way to 'wrap' Mathematica around Haskell; being able to combine the two would be interesting (and probably quite powerful).

[0] http://docs.hylang.org

you can use the Mathematica Kernel C API to make any language interface with mathematica (I did this with Python a long time ago). This typically involves the scripting langauge (or compiled language) invoking Mathematica functions, I;'m not 100% if Mathematica can then call back into Haskell or other language functions via a callback.

Reply on news.ycombinator.com