

Will Rubinius be an acceptable Lisp? - djacobs
http://on-ruby.blogspot.com/2007/01/will-rubinius-be-acceptable-lisp.html

======
djacobs
From the article's comments:

    
    
      Ruby is a language designed in the following steps:
    
      * take a simple Lisp language
      * remove macros, s-expression
      * add simple object system (simpler than CLOS)
      * add blocks, inspired by higher order functions
      * add methods found in Smalltalk
      * add functionality found in Perl (in OO way)
    

In my opinion, Ruby is already a Lisp modulo macros. But sometimes, macros and
more parens/less syntax are really nice to have.

~~~
anon_d

        - Take a simple Lisp language.
        - Remove macros, s-expression.
        - Add a bunch of shit that could be trivially added if you still had macros.

~~~
djacobs

      Add a bunch of shit that could be trivially added if you still had macros.
    

... only now, they're standard, first-class citizens across all code using the
language.

~~~
anon_d
None of the Lisp OO systems make objects feel second-class.

------
pnathan
I'd like to see - maybe one year I'll have both the time and expertise to put
work towards it - a Common Lisp that can be retargeted to different vms in a
straightforward fashion: JVM, .NET, Rubinious, llvm, etc.

While it's awesome to make yet another Lisp, I think it's far more awesome to
have a well-defined Lisp that can run on multiple places.

~~~
cabalamat
> a Common Lisp that can be retargeted to different vms in a straightforward
> fashion: JVM, .NET, Rubinious, llvm, etc. [...] awesome to have a well-
> defined Lisp that can run on multiple places

But it wouldn't. A Lisp that ran on the JVM would be able to use JVM
libraries, one that ran on .NET would be able to use .NET libraries, one that
ran on Rubinious would be able to use Ruby libraries.

Sure, the core Lisp language might be the same, but as soon as you started
doing real work connecting it to outside code/services/devices etc, it'd
rapidly become non-portable.

That doesn't mean it would be useless: being able to think in one language
over multiple platforms would reduce cognitive load for developers.

~~~
pnathan
well, yes. But what would be able to happen in A Perfect World is for the
intersection of features to have an abstraction layer.

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

~~~
djacobs

      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.

~~~
vito
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!

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

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

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

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

------
francoisdevlin
No.

