Comments on: Excellent Overview of Functional Programming http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming (permanently in beta) Sun, 29 Aug 2010 20:01:44 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: Daniel Spiewak http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3178 Daniel Spiewak Sun, 02 Mar 2008 18:08:30 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3178 Ah, very nice! The tail-calls alone should help a lot, though Scala already does some clever things to optimize tail recursion. Not sure if it'll be able to actually use the runtime-level tuple type since the APIs are already designed to use TupleN[A,B,C,...] Ah, very nice! The tail-calls alone should help a lot, though Scala already does some clever things to optimize tail recursion. Not sure if it’ll be able to actually use the runtime-level tuple type since the APIs are already designed to use TupleN[A,B,C,...]

]]> By: Joerg Gottschling http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3176 Joerg Gottschling Sun, 02 Mar 2008 12:10:10 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3176 There was this article on InfoQ about the Da Vinci Machine, which I had in mind: "The scope of the Da Vinci project is broader in that it targets both dynamic and functional languages." "The major sub-project is the implementation of dynamic invocation ..." "... adding support for tail calls and tail recursion (via a new tailcall bytecode prefix), and tuples (using a new tagged tuple signature string)." May be this will boost Scala & Co in the future. :-) There was this article on InfoQ about the Da Vinci Machine, which I had in mind:

“The scope of the Da Vinci project is broader in that it targets both dynamic and functional languages.”
“The major sub-project is the implementation of dynamic invocation …”
“… adding support for tail calls and tail recursion (via a new tailcall bytecode prefix), and tuples (using a new tagged tuple signature string).”

May be this will boost Scala & Co in the future. :-)

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3171 Daniel Spiewak Sat, 01 Mar 2008 17:30:10 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3171 I think the only FP aspects to the Da Vinci machine are improved efficiency on dispatch. It's possible that there will be some optimizations for provably immutable objects, but I somewhat doubt it. Very few functional languages seem to be targeting the JVM. More precisely, very few *pure* functional languages are targeting the JVM. So while I hope that they do some optimizations for FP, I doubt that it will be anything dramatic. I'm guessing we'll see a lot more of the effort focused on dynamic languages like JRuby, Groovy and Rhino. I think the only FP aspects to the Da Vinci machine are improved efficiency on dispatch. It’s possible that there will be some optimizations for provably immutable objects, but I somewhat doubt it. Very few functional languages seem to be targeting the JVM. More precisely, very few *pure* functional languages are targeting the JVM. So while I hope that they do some optimizations for FP, I doubt that it will be anything dramatic. I’m guessing we’ll see a lot more of the effort focused on dynamic languages like JRuby, Groovy and Rhino.

]]> By: Joerg Gottschling http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3169 Joerg Gottschling Sat, 01 Mar 2008 11:55:17 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3169 Yes, Scala does not forbid side effects. But perhaps the compiler could mark methods as side effect free and objects a immutable. Perhaps the developer should also do this, so Scala should provide this possibiblity. But what would be the benefit? Until now the JVM does not optimize code because it is immutable - as far as I know. So could the Scala compiler use these informations and generate optimized code? Does it? I've read that the Da Vinci Machine should also support FP. Perhaps it supports some optimizations in this direction. Yes, Scala does not forbid side effects. But perhaps the compiler could mark methods as side effect free and objects a immutable. Perhaps the developer should also do this, so Scala should provide this possibiblity. But what would be the benefit? Until now the JVM does not optimize code because it is immutable – as far as I know. So could the Scala compiler use these informations and generate optimized code? Does it?

I’ve read that the Da Vinci Machine should also support FP. Perhaps it supports some optimizations in this direction.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3159 Daniel Spiewak Thu, 28 Feb 2008 15:41:46 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3159 Unfortunately, program provers tend to fall on their faces when dealing with mutability and the imperative tendency toward side-effects. Because Scala is a hybrid language, it doesn't actually *forbid* side-effects, meaning that it's hard for provers to just mathematically say things about a discrete function. This is a limitation of the mathematical process itself, not really a problem with the JVM. Any pure-functional language can be fed into a prover, regardless of its runtime. As I understand it, the Da Vinci Machine project is designed simply as an extension to the JVM to allow for easier and more efficient expression of non-Java languages, especially dynamic languages like JRuby. As it is part of the runtime, it doesn't really effect a program prover's ability to make statements about an algorithm. Unfortunately, program provers tend to fall on their faces when dealing with mutability and the imperative tendency toward side-effects. Because Scala is a hybrid language, it doesn’t actually *forbid* side-effects, meaning that it’s hard for provers to just mathematically say things about a discrete function. This is a limitation of the mathematical process itself, not really a problem with the JVM. Any pure-functional language can be fed into a prover, regardless of its runtime.

As I understand it, the Da Vinci Machine project is designed simply as an extension to the JVM to allow for easier and more efficient expression of non-Java languages, especially dynamic languages like JRuby. As it is part of the runtime, it doesn’t really effect a program prover’s ability to make statements about an algorithm.

]]> By: Joerg Gottschling http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming/comment-page-1#comment-3156 Joerg Gottschling Thu, 28 Feb 2008 09:31:56 +0000 http://www.codecommit.com/blog/java/excellent-overview-of-functional-programming#comment-3156 Hello Daniel, I also like Scala and I like your blog very much, because of your good explanations of Scala. First thank you for this link. It points to a really impressive article in content and style. How does Scala fit in this description of the benefits of FP, espacially "Machine Assisted Proofs and Optimizations"? Until now the JVM does not provide these things because it is not made for functional languages. This will perhaps change in the future (Java 7?) with the Da Vinci Machine. But until now: Are the functional parts of the Scala code optimized automatically in consideration of FP technics? Greetings, Jörg Hello Daniel,

I also like Scala and I like your blog very much, because of your good explanations of Scala. First thank you for this link. It points to a really impressive article in content and style.

How does Scala fit in this description of the benefits of FP, espacially “Machine Assisted Proofs and Optimizations”? Until now the JVM does not provide these things because it is not made for functional languages. This will perhaps change in the future (Java 7?) with the Da Vinci Machine. But until now: Are the functional parts of the Scala code optimized automatically in consideration of FP technics?

Greetings, Jörg

]]>