Hacker News Reader

Comment by jameskilton | Hacker News Reader

FYI this is from 2007, though I have to imagine doing this would be even easier now that Rubinius is much more robust and stable (I mean there's an entire bootstrapped language for Rubinius now, Fancy: http://www.fancy-lang.org/)

Interesting quote from Ola though: "Ola: You can count on a JRuby-based Rubinius. It will happen. And making a Lispinius possible on JRuby would be a major reason for it." I can see this thought process getting all sorts of meta. Rubinius built again upon JRuby-Rubinius using JRLisp? Well maybe not but it's fun to fantasize.

View on HN

  FYI this is from 2007, though I have to imagine doing this
  would be even easier now that Rubinius is much more robust 
  and stable (I mean there's an entire bootstrapped language 
  for Rubinius now, Fancy: http://www.fancy-lang.org/)

That was exactly my thought process when I submitted. I would love to have a legit Lisp that jives with the Ruby ecosystem. I feel like the ecosystem can make or break a language and, while I love Clojure, dealing with all that Java (especially package structure and package management) makes me want a Ruby-friendly Lisp.

I've been working on a port of Atomo (http://atomo-lang.org/ ) to the Rubinius VM, dubbed Quanto for now. It's similar to Fancy (though they were both designed/developed separately), but one of the main differences is that it has macros (and pattern-matching everywhere).

Example code: http://toogeneric.com/dump/pretty.atomo.html

"data", "class", "module", "=", and ":=" are all Lisp-style macros. It doesn't have Lisp syntax, but it's very close to it conceptually - in fact Atomo has Lisp's condition system, and a similar string formatting system, and dynamic environment. All of which I plan to port. Fun times ahead!

interesting, how do you model multiple dispatch in an efficient way over a vm that (I believe) wasn't designed for it?

Via pattern-matching at the moment:

    X foo: Y := ...
    X foo: Z := ...

Both of these are inserted on X, which is used as `self` in the method body (so instance variables, etc. work as expected too). It's one method, `foo:`, which pattern-matches on its arguments to determine which branch to evaluate.

I see, but does this play well with the jit? What I mean is: wouldn't multimethods with many variants cause exponentially bigger thunks to inline, thus causing the JIT to not perform inlining at all?

Thanks for your answer anyway, it looks like a really fun project.

Looking at the bytecode, the JIT handles it fine. atomo pattern matching is the equivalent of using a case;when in the body. And because it's scoped to a certain class and name, I doubt it would have the overflow problem that lisp multimethods have, where you only have the name to bind functionality to.

Reply on news.ycombinator.com