This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Another opportunity for Scala?

5 replies
Blair Zajac
Joined: 2009-01-12,
User offline. Last seen 42 years 45 weeks ago.

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

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Another opportunity for Scala?
On Wed, Nov 17, 2010 at 2:07 PM, Blair Zajac <blair [at] orcaware [dot] com> 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?

Dan Shryock
Joined: 2010-01-07,
User offline. Last seen 42 years 45 weeks ago.
Re: Another opportunity for Scala?
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:

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


what about scala's structural types?
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Another opportunity for Scala?
On Wed, Nov 17, 2010 at 6:38 PM, Dan Shryock <dan [dot] shryock [at] gmail [dot] com> wrote:
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> 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?
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Another opportunity for Scala?
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 <nilskp [at] gmail [dot] com> wrote:
On Wed, Nov 17, 2010 at 6:38 PM, Dan Shryock <dan [dot] shryock [at] gmail [dot] com> wrote:
On Wed, Nov 17, 2010 at 4:27 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> 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?

Ben Lings
Joined: 2010-11-29,
User offline. Last seen 42 years 45 weeks ago.
Re: Another opportunity for Scala?

Blair Zajac 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

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland