
Mochi – Dynamically-typed language for functional and actor-style programming - harel
https://github.com/i2y/mochi
======
RussianCow
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.

------
rcarmo
Very neat, and it led me (again) to pyrsistent
([https://github.com/tobgu/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](https://github.com/hylang/hy)).

(edit: damn autocorrect!)

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

~~~
Foxboron
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.

------
Foxboron
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.

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

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

------
thinkpad20
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](https://github.com/i2y/mochi/blob/master/examples/bind.mochi)

~~~
CyberDildonics
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.

~~~
shele
Here you go!
[https://github.com/JuliaLang/FunctionalCollections.jl](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](http://www.infoq.com/presentations/julia-vectors-maps-sets)

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

~~~
seanmcdirmid
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.

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

~~~
seanmcdirmid
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.

~~~
gnufx
[http://dl.acm.org/citation.cfm?doid=365230.365257](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.

~~~
seanmcdirmid
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.

------
rssaddict
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?

------
bsaul
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
?

~~~
klibertp
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.

------
Sonata
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.

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

~~~
Goopplesoft
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.

~~~
Foxboron
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.

------
hawkw
So Mochi : Python as Scala : Java? Neato.

------
carreau
I wrote a IPython kernel so that you can mochi in your notebooks. source:
[https://github.com/Carreau/mochi-kernel](https://github.com/Carreau/mochi-
kernel) and example: [http://nbviewer.ipython.org/github/carreau/mochi-
kernel/blob...](http://nbviewer.ipython.org/github/carreau/mochi-
kernel/blob/master/Prototype%20of%20Mochi%20Kernel.ipynb)

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

~~~
dkarapetyan
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.

~~~
gingerlime
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.

------
zniperr
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.

~~~
Foxboron
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.

~~~
CGamesPlay
> 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?

~~~
breuleux
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.

------
john2x
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)

------
joshsharp
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.

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

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

