Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure++ (notes from Rich Hickey talk)

combinate.us

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Clojure++ (notes from Rich Hickey talk)

#31

Post by richhickey »

herdrick wrote: post #23
peregrine wrote: post #20

Earlier quoted context omitted.

Yes the annotations are purely optional.

Right, but the initial quote seemed to say that promoting to BigNums would no longer be automatic. But I may have misunderstood.

Correct, promotion will no longer be automatic because the semantics of primitive and auto-promoting arithmetic can't be unified (on the JVM with no fixnums, the return types are disjoint). However, missing from the blog post and discussion here is the fact that, should there be overflow, an exception will be thrown. We are not adopting the silent error strategy of C/Java etc.

Re: Clojure++ (notes from Rich Hickey talk)

#32

Post by djacobs »

silentbicycle wrote: post #21
djacobs wrote: post #6

Earlier quoted context omitted.

Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?

"(inc clojure)". which is probably really good marketing. (About e.g. "succ ml", I'm not sure.)

Well, I agree with you that isn't fantastic marketing. But neither is using a mutator function name to describe a talk on a functional language.

Rich Hickey loves to rail against nonsensical constructs/concepts like @date.day = 3, and I'm guessing he is very against the (++) method, as well. (How can you tell one number to become another number?)

Re: Clojure++ (notes from Rich Hickey talk)

#33

Post by djacobs »

lmkg wrote: post #11
djacobs wrote: post #6

Earlier quoted context omitted.

Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?

(swap! clojure inc) is acceptable and a more literal translation, although refactoring your code to use (inc clojure) is usually more idiomatic. See also, ADD 1 TO COBOL GIVING COBOL.

My point was not to translate the method name, it was to point out that (++) is anti-Clojure. I wanted to refactor the title to avoid mutability. I.e., "return the increment of clojure", not "change the value of clojure".

Re: Clojure++ (notes from Rich Hickey talk)

#34

Post by silentbicycle »

djacobs wrote: post #32
silentbicycle wrote: post #21

Earlier quoted context omitted.

"(inc clojure)". which is probably really good marketing. (About e.g. "succ ml", I'm not sure.)

Well, I agree with you that isn't fantastic marketing. But neither is using a mutator function name to describe a talk on a functional language. Rich Hickey loves to rail against nonsensical constructs/concepts like @date.day = 3, and I'm guessing he is very against the (++) method, as well. (How can you tell one number to become another number?)

I haven't done anything with Clojure, though I'm curious and wondering if would be worth my while. I'm already familiar with languages covering similar territory (Erlang, other Lisp dialects), but I haven't done much with the JVM. Also, the lack of tail-call optimization in Clojure is off-putting to me, but it looks several good design trade-offs elsewhere would probably make up for it.

(I was thinking of tattoos, PS.)

Re: Clojure++ (notes from Rich Hickey talk)

#36

Post by djacobs »

silentbicycle wrote: post #34
djacobs wrote: post #32

Earlier quoted context omitted.

Well, I agree with you that isn't fantastic marketing. But neither is using a mutator function name to describe a talk on a functional language. Rich Hickey loves to rail against nonsensical constructs/concepts like @date.day = 3, and I'm guessing he is very against the (++) method, as well. (How can you tell one number to become another number?)

I haven't done anything with Clojure, though I'm curious and wondering if would be worth my while. I'm already familiar with languages covering similar territory (Erlang, other Lisp dialects), but I haven't done much with the JVM. Also, the lack of tail-call optimization in Clojure is off-putting to me, but it looks several good design trade-offs elsewhere would probably make up for it. (I was thinking of tattoos, PS…

I did not get the tatoo reference, haha. As far as I understand, though, there is TCO in Clojure, right? You just have to be explicit and use (recur).

Re: Clojure++ (notes from Rich Hickey talk)

#37

Post by silentbicycle »

djacobs wrote: post #36
silentbicycle wrote: post #34

Earlier quoted context omitted.

I haven't done anything with Clojure, though I'm curious and wondering if would be worth my while. I'm already familiar with languages covering similar territory (Erlang, other Lisp dialects), but I haven't done much with the JVM. Also, the lack of tail-call optimization in Clojure is off-putting to me, but it looks several good design trade-offs elsewhere would probably make up for it. (I was thinking of tattoos, PS…

I did not get the tatoo reference, haha. As far as I understand, though, there is TCO in Clojure, right? You just have to be explicit and use (recur).

That's not TCO, that's just an optimization for individual recursion. You might be able to use it for multiple forms under the same recur (like w/ "labels"), but it's very different when it applies to everything.

With TCO, you can use a set of mutually-recursive functions - you can set up a FSM via tail calls, use CPS for backtracking (and many other things), a re-entrant virtual machine where each opcode is a tail call (rather than a giant switch/case or lots of gotos), etc. Being able to use function calls like "gotos with arguments" (but with local scopes, etc.) can make some constructs much easier to read, reason about, etc.

I'm not that familiar with the implementation of the JVM, but AFAICT it's due to difficulties setting up tail calls efficiently in JVM bytecode.

Re: Clojure++ (notes from Rich Hickey talk)

#38

Post by bitsai »

silentbicycle wrote: post #37
djacobs wrote: post #36

Earlier quoted context omitted.

I did not get the tatoo reference, haha. As far as I understand, though, there is TCO in Clojure, right? You just have to be explicit and use (recur).

That's not TCO, that's just an optimization for individual recursion. You might be able to use it for multiple forms under the same recur (like w/ "labels"), but it's very different when it applies to everything. With TCO, you can use a set of mutually -recursive functions - you can set up a FSM via tail calls, use CPS for backtracking (and many other things), a re-entrant virtual machine where each opcode is a tail…

You can do optimized mutual-recursion in Clojure as well, using (trampoline). As with the optimized self-recursion using (recur), it's more work and not as nice as built-in TCO, but this is likely as good as it gets for now, given the current limitations of the JVM.

Re: Clojure++ (notes from Rich Hickey talk)

#39

Post by tvachon »

rbanffy wrote: post #4

shouldn't it be called (++ clojure) or something like it?

I guess the right thing to do would be to claim I was being ironic here, but really, it was just a poorly thought out late night titling decision.

If I could do it again, I'd go with (inc clojure), as below.

Re: Clojure++ (notes from Rich Hickey talk)

#40

Post by nickik »

silentbicycle wrote: post #37
djacobs wrote: post #36

Earlier quoted context omitted.

I did not get the tatoo reference, haha. As far as I understand, though, there is TCO in Clojure, right? You just have to be explicit and use (recur).

That's not TCO, that's just an optimization for individual recursion. You might be able to use it for multiple forms under the same recur (like w/ "labels"), but it's very different when it applies to everything. With TCO, you can use a set of mutually -recursive functions - you can set up a FSM via tail calls, use CPS for backtracking (and many other things), a re-entrant virtual machine where each opcode is a tail…

Rich is very mutch pro tail calls. Look at his talk at the JVM Language http://wiki.jvmlangsummit.com/What_the_JVM_needs (the video is not online jet).

As soon as the JVM supports it Clojure will support it. For me recur and trampoline are quite ok. I would want to miss on clojure because of TCO but I don't know what would be possible with TCO. I hope I can learn that in one of the books I have here :)

Post reply on HN