Timothy Baldridge writes: > That's why I think it's a good idea to ask what the goals are for native > Clojure. The > ClojureScript and Clojure-Py options while nice both don't allow for a good > concurrency > story. On top of that, I'm not sure either of those would actually run on > iOS. > > However, a pure, from-scratch option has a much smaller ecosystem to draw > from. But on > the upside, you're also not limited by the host VM. This means that the type > system > could be based purely on protocols instead of having to fit protocols into a > OOP type > system.
Another approach that might be worth exploring (for someone who has lots more time than me for such a project) is hijacking the implementation of the Julia language (http://julialang.org/). It's a language with many Lisp inspirations, despite its non-Lisp syntax, and it's based on LLVM with no virtual machine in between, but a run-time system with a garbage collector. It's data model is much more similar to Clojure's than to classic OOP, with all functions essentially being multimethods. A native Clojure implementation could probably re-use much of Julia's implementation. Konrad. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
