Another opportunity for Scala?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Another opportunity for Scala?

Blair Zajac-3
Saw this today:

"""An earlier version of JSR 292 included some syntax support in the
Java language for issuing invokedynamic instructions. This is no longer
the case in JDK 7. Such support, if it shows up at all, will be
dependent on Project Lambda, and that is after JDK 7."""

http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing

Could there be anything Scala could do to make invokedynamic
instructions supported in the language, before JDK 8, for people
interested in performance?

Blair
Reply | Threaded
Open this post in threaded view
|

Re: Another opportunity for Scala?

Nils Kilden-Pedersen
On Wed, Nov 17, 2010 at 2:07 PM, Blair Zajac <[hidden email]> wrote:
Saw this today:

"""An earlier version of JSR 292 included some syntax support in the Java language for issuing invokedynamic instructions. This is no longer the case in JDK 7. Such support, if it shows up at all, will be dependent on Project Lambda, and that is after JDK 7."""

http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing

Could there be anything Scala could do to make invokedynamic instructions supported in the language, before JDK 8, for people interested in performance?

Isn't invokedynamic primarily intended for weakly typed languages? How would Scala benefit?

Reply | Threaded
Open this post in threaded view
|

Re: Another opportunity for Scala?

Dan Shryock
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <[hidden email]> wrote:

Isn't invokedynamic primarily intended for weakly typed languages? How would Scala benefit?


what about scala's structural types?
Reply | Threaded
Open this post in threaded view
|

Re: Another opportunity for Scala?

Nils Kilden-Pedersen
On Wed, Nov 17, 2010 at 6:38 PM, Dan Shryock <[hidden email]> wrote:
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <[hidden email]> wrote:

Isn't invokedynamic primarily intended for weakly typed languages? How would Scala benefit?


what about scala's structural types?

Perhaps, but how often do you need those?
Reply | Threaded
Open this post in threaded view
|

Re: Another opportunity for Scala?

Martin Odersky
I think there's an opportunity to better integrate with dynamic languages, independently of invokedynamic support. There are now quite a few of those languages on the JVM platform (Groovy, JRuby, Jython, Clojure, JavaScript, ...) so anything we can do to make co-existing with them easier would be a good thing.

Cheers

 -- Martin

On Thu, Nov 18, 2010 at 2:21 AM, Nils Kilden-Pedersen <[hidden email]> wrote:
On Wed, Nov 17, 2010 at 6:38 PM, Dan Shryock <[hidden email]> wrote:
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <[hidden email]> wrote:

Isn't invokedynamic primarily intended for weakly typed languages? How would Scala benefit?


what about scala's structural types?

Perhaps, but how often do you need those?

Reply | Threaded
Open this post in threaded view
|

Re: Another opportunity for Scala?

Ben Lings
In reply to this post by Blair Zajac-3
Blair Zajac <blair <at> orcaware.com> writes:

>
> Saw this today:
>
> """An earlier version of JSR 292 included some syntax support in the
> Java language for issuing invokedynamic instructions. This is no longer
> the case in JDK 7. Such support, if it shows up at all, will be
> dependent on Project Lambda, and that is after JDK 7."""
>
> http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing
>
> Could there be anything Scala could do to make invokedynamic
> instructions supported in the language, before JDK 8, for people
> interested in performance?

I think the MethodHandle parts of JSR 292 would have more immediate benefit.

From reading the proposed lambda-expression translation document [1], it looks
like using a similar scheme in Scala could significantly reduce the number of
classes generated for instances of FunctionN.  

In particular, functions that don't capture any state could be implemented as
private methods and functions that capture vals could be implemented as curried
private methods.

[1]: http://cr.openjdk.java.net/~mcimadamore/lambda_trans.pdf