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.
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.
> 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.
Clojure's primary target is the JVM and they had an officially supported CLR(.NET) branch for a while (and it's now supported by a 3rd party https://github.com/richhickey/clojure-clr). I wouldn't be surprised if in the future portability became a bigger concern within the Clojure community (http://blog.n01se.net/?p=41).
(That said I realize you were looking for a Common Lisp, but sometimes good enough is good enough ;) )
That's one of the goals of the Clojure team. While the main 'branch' targets the JVM, there is also a branch targeting .NET. And there is an initiative, Clojure-in-Clojure, to de-couple the main branch from the JVM as much as possible, to facilitate re-targeting.
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.
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).
"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!
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.
