Mochi – Dynamically-typed language for functional and actor-style programming | Hacker News Reader

Mochi – Dynamically-typed language for functional and actor-style programming

github.com

205 pointsharel47 comments

I'm really glad we're starting to see compile-to-Python languages crop up. Don't get me wrong, Python is a great language, and the community around it is fantastic, but it's missing key functional/concurrency features that would make certain problems much less tedious to solve. For instance, I love the built-in use of persistent data structures in Mochi--that's something that's sorely missing from the Python standard library.

Very neat, and it led me (again) to pyrsistent (https://github.com/tobgu/pyrsistent), which does persistent data structures and which I've been pondering using with Hy (https://github.com/hylang/hy).

(edit: damn autocorrect!)

I thought Hy already used persistent data structures? If not, then it should! :)

No! :D

Hy aims to be bidirectional. Swapping around data structures will mess with that. Hy doesn't want to be intrusive, you should really be able to tell when you use Hy code.

I really found this project neat. Core dev on Hy and i was wondering how well hy works when importing it into mochi. Guess what? It just works!

    >>> import hy
    None
    >>> from foobar import test ;; Hy module
    None
    >>> test()
    Test
    None
    >>>

EDIT: From looking at the source, it look's like Mochi is actually a lisp, without the parens. Really neat.

you could say that python is actually a lisp, except it exchanged lists for dicts.

You mean MISC http://lambda-the-ultimate.org/node/2887 ;)

You "could" say many different things, but that won't make them true.

Super cool stuff. I'm a fan of statically typed languages as a rule, but do python at my job, so this is very relevant to me. I've long thought there should be (and have half-assedly attempted to make) a simple, python-like dynamically typed language which supports functional staples such as pattern matching, expression syntax (i.e. no need for explicit return), records and the like. And it has persistent data structures, which are (inexplicably) still missing from python after all these years. Bravo!

The one thing I didn't see, though: lambdas? Is it python syntax for those? Is there support for pattern matching inside of lambdas?

Edit: another user posted this link re: lambdas. https://github.com/i2y/mochi/blob/master/examples/bind.mochi

You should have a look at Elixir. It's a simple, dynamic, functional language running on top of BEAM, the Erlang VM.

It recently reached 1.0 and is production ready: http://elixir-lang.org/

Python IS dynamically typed. You seem to be confusing the fact that it's strongly typed with statically typed languages.

https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

Where in my post did I suggest otherwise? I realize I didn't word it the clearest way but I don't think I ever indicated that python was anything but dynamically typed. To be clearer:

* I prefer statically typed languages as a rule

* However, I do python at my job (which is not statically typed)

* there are many features which tend to be found in statically typed functional languages, which I would love to see in a dynamically typed, python-like language.

You should take a look at Julia. It does not have pattern matching, but it does have multiple dispatch and pretty much every other functional programming staple. I don't know about persistent data structures but someone may have already done it, or it could be done with macros.

Here you go! https://github.com/JuliaLang/FunctionalCollections.jl There is a nice talk by Zach Allaun, of Clojure background, about persistent data structures in julia, http://www.infoq.com/presentations/julia-vectors-maps-sets

Probably gonna get downvoted for this, but I'm a fan of the python-style syntax. Nice work!

Well, it does compile down to Python 3 AST, so it makes a certain amount of sense. :)

I don't think off-side rule languages get enough credit; python probably has the best syntax aesthetics of any language out there. I like how the author realized a bunch of interesting features (pattern matching) with this syntax.

I'm a fan of python myself, but what does 'off-side rule' mean?

I'm on mobile, so can't easily find a link. But its basically the term landen used to describe using indentation to delimit block structure. There is a wiki page on it.

Ok, I figured as much. I've only ever seen 'significant whitespace' to describe this, but I guess that's not very clear either. I myself do like it as well, I just wish tabs were the default for indenting in editors and general best practices instead of spaces.

I'm a big believer in amped up language specific editors to deal with that (http://research.microsoft.com/en-us/projects/liveprogramming...).

http://dl.acm.org/citation.cfm?doid=365230.365257 and gratis copies elsewhere; required reading since 1966. Of course "off-side" is a football term, somewhat significant in England later that year.

However, Python doesn't use Landin's off-side rule; colons are required, c.f. Haskell's usual syntax. Emacs works anyhow.

I prefer Python's use of colons to haskell's nothingness. Now...that means colons can't be used for types or cons, but it makes a lot of sense for python.

The pattern-matching, actors, and pipeline operator seem like they were inspired by Elixir. Was that a conscious source of ideas or just stuff you came across elsewhere and thought was good?

Isn't actor-style programming a bit problematic when your interpreter has a GIL ? Aren't actor supposed to be executed in parallel for maximum performance ?

it is using eventlet in the background, so for IO-bound tasks you will see concurrency, but I would imagine that CPU-bound tasks will still be hampered by the GIL in the same way that vanilla Python is.

I don't think that there is a requirement for Actors to run in parallel. Rather, they have to run concurrently, and may run in parallel - I think.

This looks fantastic. Python always feels like it's almost as good as a dynamic, imperative language could get, but I miss some of the functional idioms from other languages. It's great that this is just a thin layer over Python too, so it can hook into the ecosystem, and it's a realistically sized project for a single developer to maintain.

Could anybody tell me why somebody would prefer mochi over f#? Granted its not dynamically typed but it has strong type inference.

It's written and supports python fully (see flask snippet and source). The code was definitely an interesting read. Really cool and well done OP.

My only gripe is that unfortunately the reverse isn't true (you can't 'mochi' in python). I wonder how much could be achieved with a 'Dynamic functional programming for humans' type thing that stays pure python.

It compiles to AST, so he could just do the same we did in Hy, write a import hook and stuff the compiled AST back as an module. Then python should be able to use mochi without many limitations.

So Mochi : Python as Scala : Java? Neato.

I wrote a IPython kernel so that you can mochi in your notebooks. source: https://github.com/Carreau/mochi-kernel and example: http://nbviewer.ipython.org/github/carreau/mochi-kernel/blob...

This is fascinating and makes me wonder if someone will try to build something similar for Ruby.

Ruby is already very DSL friendly so writing something on top of it that at the end of the day just compiles down to Ruby does not provide the same kind of power/effort ratio as in the Python case. Plus there's already elixir which covers similar territory.

True. But being able to use something like actors or functional constructs, immutable data structures etc from within rails for example, could be neat. If it's baked into the language this way it enforces those ideas better. Using elixir could be great but it's a much bigger jump from the ruby ecosystem.

At first glance this seems to be for Python what Coffeescript is to Javascript, and I love Coffeescript (mostly).

I would be interested to see some performance comparisons with regular Python.

No not at all.

Coffeescript is a transpiler. It converts its own code directly into javascript code. This project converts its code to AST, not Python code itself. You can generate the Python code off from the AST, but it dosnt always imply the resulting Python code is runable.

> You can generate the Python code off from the AST, but it dosnt always imply the resulting Python code is runable.

I believe this is incorrect. Can you show an example of a valid abstract syntax tree that could not be represented in the grammar of the original language?

I know that variable names in Python's AST can be any string, so for instance you could declare and use a variable named "+a-b$ $$?", even though that's not valid Python code. That's pretty minor, though, so I'm curious if there's anything more significant.

We got this very "problem" in Hy. AST allows for several characters as Names, where python does not.

A great example is with gensym, here we will make an ast.Name node with a prefix ":", if you run astor over this, you produce AST containing that very character. What happens if you try run this Python code? Syntax error. There is also a few other cases i can't think off right now.

This is amazing. I really hope this picks up and becomes production ready.

What technical factors could prevent this from being used in production? (not right now, but in the future)

This looks a lot like Elixir to me, which is exciting. Elixir has great ideas, but Python has much more in the way of ecosystem and libraries. It's an appealing idea to have pattern matching and concurrency on top of the libraries I take for granted.

Even the macros look very similar. Surely this has drawn inspiration from Elixir.

Can't tell if actors are language- or library- level.

From the docs, I'm not sure if they really qualify as actors. There's no mention of hot-swapped behavior or supervisor hierarchies.

Reply on news.ycombinator.com