The only dependency to the JVM would be the advantage of integrating with the Java ecosystem.
When compiling Clojure to native code, you won't be able to use Java libraries, unless the native compiler can also generate native code for .class files.
Implementations already exist for the CLR as well as Python, C, Scheme, and of course JavaScript. LLVM appears to be in the thinking stage still: https://github.com/halgari/clojure-metal
I would be very curious to understand the runtime implications of imposing immutability on an Objective-C program. Presumably porting that was a lot of work.
If by runtime implications you mean speed, I think it'd be ok. Objective-C makes heavy use of immutable data structures already, and iPhone apps just don't have that much data, anyway.
Many Cocoa classes are immutable (NSString, NSDictionary, NSArray). You can use the mutable versions (i.e. NSMutableString, NSMutableDictionary, NSMutableArray) but there's no reason to if the immutable versions are a better fit for clojurem.
I haven't looked at the source, but the avoidance of full copy-on-write, laziness and instrumentation of immutable structures when returning from functions that update / assoc them will be non-trivial to get right. Not even to mention software transactional memory Clojure supports at all.
Immutability in general isn't that big of a deal. The problem is that Clojure uses persistent trees for all datastructures, which will trigger alot of retain/release calls. Other than some RC overhead, it should work just fine. A GC would be ideal however.
I took a different tack with clojure-scheme by compiling via Gambit Scheme, which can target Objective-C. https://github.com/takeoutweight/clojure-scheme. This approach made it easier to provide self-hosted compilation, enabling niceties like an on-device repl.
I recently wanted to try out clojure-scheme for a simple Mac OS X or iOS app, but I couldn't easily find an example app that shows how to set up a project to target Objective-C and compile correctly, and what to import to call the Apple frameworks.
Is that even possible? If yes, is there some sort of sample that I didn't see?
The best place to start is actually the scheme iOS repl that comes packaged with the Gambit source. Take a look at the misc/build-gambit-iOS script (mentioned on slide 39,40 of my linked talk slides). It's a bit of a hairy build process (and clojure-scheme only adds more hair into the mix) but once you have the repl working it's easier to see where to slide in the .scm/.m files that clojure-scheme and Gambit generate. Some kind of CMake script would probably ease this pain in setting up all this Xcode stuff.
Clojure's one real advantage is Java interoperability and it is its biggest single selling point.
You just can code nice and quick in a language much nicer than Java, but easily access all that code from our_stalled_corporate_crap.jar, and package/deploy it the way they do it in their Java EE world.
Persistent datastructures, STM, CAS concurrency primitives and hygenic macros make no sense outside of the JVM? Please...
Clojure has host language interop, this isn't necessarily the same as Java interop. It would be very nice to write an iOS app using Clojure for instance.
Nitpic: Clojure delegates most things to the VM. The subtle difference that it works just fine on JS engines and CLR.
Arc and Golang would not be a good idea. I'm not trying to be overly negative, but Arc does have it's issues, the main thing being that Arc does not always work, meaning you would need some tool to hunt down leaks. RC is also slower than GC for several reasons, and when you require a runtime anyway for goroutines, you might as well include a GC, especially since Go can have a precise GC.
So, just out of curiosity, how would you even begin planning such a task? Let's say you want to do something simple, like an analogue clock app that takes minimal user input (maybe a few look and feel settings). How would you structure that in Clojure in general, and Clojure-for-iOS in particular?
I would store application state in a atomic reference, and have "time" be updated every second by a timer. I would add a watch to the application state, so that every time application state changes, the UI is re-drawn. At least that's how I do most UI-apps in ClojureScript (re-draw auto magically when state changes).
You'd do the same in Clojure-for-iOS. Of course, since you rely on Apples SDK for UI, you would use interop to subclass whatever needs subclassing, but the principle remains the same.
You could have that in principle in any language. In Clojure it's built-in and idiomatic.
Besides, there are people who prefer Clojure over Common Lisp and Scheme. You asked why anyone would want Clojure without the JVM, I just told you there are many benefits, especially if your prefered language already is Clojure.
Haskell really is something entirely diffrent than Clojure. Staticly typed, monads, template haskell. It's a nice language, but not as easy to use as Clojure IMHO.
There are at least two alternatives to ClojureM; iOS7 runs js directly so ClojureScript can be used with a certain amount of fiddling. There is also a method of compiling Java into objective-c that is built into the Clojure Nightcode IDE. I ran some basic experiments over the holidays and both methods work, although there are inevitable trade offs.
Targeting another popular platform, Objective-C with the Apple libraries, makes a lot of sense to me. That, and C#/.NET (which is already a thing with clojure-clr) seem like the obvious candidates.
40 comments
[ 3.4 ms ] story [ 77.1 ms ] thread[1] https://github.com/joshaber/clojurem/tree/refactor-fns
I would really like to see a Clojure on LLVM project though. Maybe speed won't be better, but memory usage and boot times might.
When compiling Clojure to native code, you won't be able to use Java libraries, unless the native compiler can also generate native code for .class files.
I saw the Xcode requirement but I had hopes it would work on Linux.
Is that even possible? If yes, is there some sort of sample that I didn't see?
You just can code nice and quick in a language much nicer than Java, but easily access all that code from our_stalled_corporate_crap.jar, and package/deploy it the way they do it in their Java EE world.
Clojure outside Java ecosystem makes no sense.
Clojure has host language interop, this isn't necessarily the same as Java interop. It would be very nice to write an iOS app using Clojure for instance.
One of Clojure's big advantages is that it uses the JVM. One of Clojure's big disadvantages is... that it uses the JVM.
Clojure is a very clever scripting language for JRE.)
I think that it is good idea to marry Arc and Golang in the same way.)
Arc and Golang would not be a good idea. I'm not trying to be overly negative, but Arc does have it's issues, the main thing being that Arc does not always work, meaning you would need some tool to hunt down leaks. RC is also slower than GC for several reasons, and when you require a runtime anyway for goroutines, you might as well include a GC, especially since Go can have a precise GC.
You'd do the same in Clojure-for-iOS. Of course, since you rely on Apples SDK for UI, you would use interop to subclass whatever needs subclassing, but the principle remains the same.
And, you know, except for reader macros, Haskell..) Let's take it easy - I am familiar with the concepts Clojure is based upon.
Besides, there are people who prefer Clojure over Common Lisp and Scheme. You asked why anyone would want Clojure without the JVM, I just told you there are many benefits, especially if your prefered language already is Clojure.
Haskell really is something entirely diffrent than Clojure. Staticly typed, monads, template haskell. It's a nice language, but not as easy to use as Clojure IMHO.
At the very least, ClojureCLR and ClojureScript most certainly do make sense.