Problem: Java and Scala interoperability in 2.8.0.RC1

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

Problem: Java and Scala interoperability in 2.8.0.RC1

Kazumi Okamoto
Hi,

I'd like to invoke Scala code from Java.
I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
but these codes can't be compiled in Scala 2.8.0.RC1.

Here is the snippet code in TestFunctions.java

// TestFunctions.java
import scala.*;

public class TestFunctions {
  static public Function0<Integer> test1 = new Function0<Integer>() {
      public Integer apply() { return 0; }
  };

  static public Function0<String> test2 = new Function0<String>() {
      public String apply() { return "aaaa"; }
  };
}


Here is the compile error:

$ javac -cp ../lib/scala-library.jar TestFunctions.java
TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
does not override abstract method apply$mcD$sp() in scala.Function0
      public Integer apply() { return 0; }
                     ^
TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
does not override abstract method apply$mcD$sp() in scala.Function0
      public String apply() { return "aaaa"; }
                    ^
2 errors

I have two questions.

1. Is this scala 2.8.0 RC1 bug or is the specification of
interoperability between Scala and Java changed?
2. Are there any hints to modify this compile error?

My environments are the followings:

OS: Mac OSX 10.6.3
Java:
 java version "1.6.0_17"
 Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
 Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)

Scala:
 Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL

Regards,
K.Okamoto
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Jason Zaugg
Specialization was enabled by default in RC1, and there were a few
bugs reported and subsequently fixed. You can probably workaround the
problem with the compiler option -no-specialization.

The imminent (?) RC2 release should solve the problem, if not raise a bug.

-jason

On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto <[hidden email]> wrote:

> Hi,
>
> I'd like to invoke Scala code from Java.
> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
> but these codes can't be compiled in Scala 2.8.0.RC1.
>
> Here is the snippet code in TestFunctions.java
>
> // TestFunctions.java
> import scala.*;
>
> public class TestFunctions {
>  static public Function0<Integer> test1 = new Function0<Integer>() {
>      public Integer apply() { return 0; }
>  };
>
>  static public Function0<String> test2 = new Function0<String>() {
>      public String apply() { return "aaaa"; }
>  };
> }
>
>
> Here is the compile error:
>
> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
> does not override abstract method apply$mcD$sp() in scala.Function0
>      public Integer apply() { return 0; }
>                     ^
> TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
> does not override abstract method apply$mcD$sp() in scala.Function0
>      public String apply() { return "aaaa"; }
>                    ^
> 2 errors
>
> I have two questions.
>
> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> interoperability between Scala and Java changed?
> 2. Are there any hints to modify this compile error?
>
> My environments are the followings:
>
> OS: Mac OSX 10.6.3
> Java:
>  java version "1.6.0_17"
>  Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>  Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>
> Scala:
>  Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>
> Regards,
> K.Okamoto
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Kazumi Okamoto
Jason,

Thank you for your reply.

> Specialization was enabled by default in RC1, and there were a few
> bugs reported and subsequently fixed. You can probably workaround the
> problem with the compiler option -no-specialization.

Because I want to compile my java code with scala-library.jar by javac,
I can't use the scalac compiler option.

Regards,
K.Okamoto

2010/5/5 Jason Zaugg <[hidden email]>:

> Specialization was enabled by default in RC1, and there were a few
> bugs reported and subsequently fixed. You can probably workaround the
> problem with the compiler option -no-specialization.
>
> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>
> -jason
>
> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto <[hidden email]> wrote:
>> Hi,
>>
>> I'd like to invoke Scala code from Java.
>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>
>> Here is the snippet code in TestFunctions.java
>>
>> // TestFunctions.java
>> import scala.*;
>>
>> public class TestFunctions {
>>  static public Function0<Integer> test1 = new Function0<Integer>() {
>>      public Integer apply() { return 0; }
>>  };
>>
>>  static public Function0<String> test2 = new Function0<String>() {
>>      public String apply() { return "aaaa"; }
>>  };
>> }
>>
>>
>> Here is the compile error:
>>
>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>> TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
>> does not override abstract method apply$mcD$sp() in scala.Function0
>>      public Integer apply() { return 0; }
>>                     ^
>> TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
>> does not override abstract method apply$mcD$sp() in scala.Function0
>>      public String apply() { return "aaaa"; }
>>                    ^
>> 2 errors
>>
>> I have two questions.
>>
>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>> interoperability between Scala and Java changed?
>> 2. Are there any hints to modify this compile error?
>>
>> My environments are the followings:
>>
>> OS: Mac OSX 10.6.3
>> Java:
>>  java version "1.6.0_17"
>>  Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>  Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>
>> Scala:
>>  Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>
>> Regards,
>> K.Okamoto
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Jason Zaugg
Oh, I see, that's a tricky problem. It seems that specialized traits
can't be (easily) extended from Java.

You could make a scala class to bridge between the abstract,
specialized methods on the interface Function0 and your java subclass.
The scala compiler will generate default implementations of the
specialised versions of apply. (e.g. apply$mcD$sp)

  // scala
  class MyFunction0[+R] extends Function0[R]

  // java
  public Function0<String> test2 = new MyFunction0<String>() {
        public String apply() { return "aaaa"; }
  };

You can learn more about the internals of specialization from this
presentation [1].

-jason

[1] http://days2010.scala-lang.org/node/138/151

On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto <[hidden email]> wrote:

> Jason,
>
> Thank you for your reply.
>
>> Specialization was enabled by default in RC1, and there were a few
>> bugs reported and subsequently fixed. You can probably workaround the
>> problem with the compiler option -no-specialization.
>
> Because I want to compile my java code with scala-library.jar by javac,
> I can't use the scalac compiler option.
>
> Regards,
> K.Okamoto
>
> 2010/5/5 Jason Zaugg <[hidden email]>:
>> Specialization was enabled by default in RC1, and there were a few
>> bugs reported and subsequently fixed. You can probably workaround the
>> problem with the compiler option -no-specialization.
>>
>> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>>
>> -jason
>>
>> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto <[hidden email]> wrote:
>>> Hi,
>>>
>>> I'd like to invoke Scala code from Java.
>>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>>
>>> Here is the snippet code in TestFunctions.java
>>>
>>> // TestFunctions.java
>>> import scala.*;
>>>
>>> public class TestFunctions {
>>>  static public Function0<Integer> test1 = new Function0<Integer>() {
>>>      public Integer apply() { return 0; }
>>>  };
>>>
>>>  static public Function0<String> test2 = new Function0<String>() {
>>>      public String apply() { return "aaaa"; }
>>>  };
>>> }
>>>
>>>
>>> Here is the compile error:
>>>
>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>> TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>      public Integer apply() { return 0; }
>>>                     ^
>>> TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>      public String apply() { return "aaaa"; }
>>>                    ^
>>> 2 errors
>>>
>>> I have two questions.
>>>
>>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>>> interoperability between Scala and Java changed?
>>> 2. Are there any hints to modify this compile error?
>>>
>>> My environments are the followings:
>>>
>>> OS: Mac OSX 10.6.3
>>> Java:
>>>  java version "1.6.0_17"
>>>  Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>>  Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>>
>>> Scala:
>>>  Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>>
>>> Regards,
>>> K.Okamoto
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Yukinori NAKATA
In reply to this post by Kazumi Okamoto
Hi, Kazumi

> >> I have two questions.
> >>
> >> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> >> interoperability between Scala and Java changed?
> >> 2. Are there any hints to modify this compile error?

I'm just a user, so I don't know the answer for the question 1.

But for the question 2, the following code can be complied.
(And I think it should  work.)

Seeing the source code, @specialized annotation was added to
scala.Function0 since Scala 2.8.0.RC1.

Therefore, it seems that those who use scala.Function0 from Java codes
must implement so many auto-generated method.
(Those who use scala.Function1 from Java codes would be in dead stuck...)

I also want to know the answer for question 1 :)

-------
import scala.*;

public class TestFunctions {
  static public Function0<Integer> test1 = new Function0<Integer>() {
    public Integer apply() {
      return 0;
    }

    public void apply$mcV$sp() {
      Function0$class.apply$mcV$sp(this);
    }

    public boolean apply$mcZ$sp() {
      return Function0$class.apply$mcZ$sp(this);
    }

    public byte apply$mcB$sp() {
      return Function0$class.apply$mcB$sp(this);
    }

    public short apply$mcS$sp() {
      return Function0$class.apply$mcS$sp(this);
    }

    public char apply$mcC$sp() {
      return Function0$class.apply$mcC$sp(this);
    }

    public int apply$mcI$sp() {
      return Function0$class.apply$mcI$sp(this);
    }

    public long apply$mcL$sp() {
      return Function0$class.apply$mcL$sp(this);
    }

    public float apply$mcF$sp() {
      return Function0$class.apply$mcF$sp(this);
    }

    public double apply$mcD$sp() {
      return Function0$class.apply$mcD$sp(this);
    }

  };

  static public Function0<String> test2 = new Function0<String>() {
    public String apply() {
      return "aaaa";
    }

    public void apply$mcV$sp() {
      Function0$class.apply$mcV$sp(this);
    }

    public boolean apply$mcZ$sp() {
      return Function0$class.apply$mcZ$sp(this);
    }

    public byte apply$mcB$sp() {
      return Function0$class.apply$mcB$sp(this);
    }

    public short apply$mcS$sp() {
      return Function0$class.apply$mcS$sp(this);
    }

    public char apply$mcC$sp() {
      return Function0$class.apply$mcC$sp(this);
    }

    public int apply$mcI$sp() {
      return Function0$class.apply$mcI$sp(this);
    }

    public long apply$mcL$sp() {
      return Function0$class.apply$mcL$sp(this);
    }

    public float apply$mcF$sp() {
      return Function0$class.apply$mcF$sp(this);
    }

    public double apply$mcD$sp() {
      return Function0$class.apply$mcD$sp(this);
    }

  };
}

Best Regards,
--
Yukinori NAKATA <[hidden email]>

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Reply | Threaded
Open this post in threaded view
|

difference between "() => { doStuff() }" and "{ doStuff()}"

Dennis Haupt-2
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?
Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Luc Duponcheel
semantically there is really no much difference
 
syntactically "=> T" is more convenient for DSL's than "() => T"
 
for example:it is possible to define a 'while' function (having "=> T" parameters)
that can be called using natural while(condition){someCode} use-site syntax
 
by the way: I aways found it strange that Scala supports
functions with zero parameter lists but does not support
function values with zero parameter lists (maybe making
CBV parameters unnecessary (?))
 
Luc

On Tue, May 4, 2010 at 8:46 PM, HamsterofDeath <[hidden email]> wrote:
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?



--
  __~O
 -\ <,
(*)/ (*)

reality goes far beyond imagination

Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Mark Harrah
In reply to this post by Jason Zaugg
On Tuesday 04 May 2010, Jason Zaugg wrote:
> Oh, I see, that's a tricky problem. It seems that specialized traits
> can't be (easily) extended from Java.
>
> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)

In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used.  I don't know if it is considered an implementation detail or subject to change, though.

-Mark

>   // scala
>   class MyFunction0[+R] extends Function0[R]
>
>   // java
>   public Function0<String> test2 = new MyFunction0<String>() {
>         public String apply() { return "aaaa"; }
>   };
>
> You can learn more about the internals of specialization from this
> presentation [1].
>
> -jason
>
> [1] http://days2010.scala-lang.org/node/138/151
>
> On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto <[hidden email]> wrote:
> > Jason,
> >
> > Thank you for your reply.
> >
> >> Specialization was enabled by default in RC1, and there were a few
> >> bugs reported and subsequently fixed. You can probably workaround the
> >> problem with the compiler option -no-specialization.
> >
> > Because I want to compile my java code with scala-library.jar by javac,
> > I can't use the scalac compiler option.
> >
> > Regards,
> > K.Okamoto
> >
> > 2010/5/5 Jason Zaugg <[hidden email]>:
> >> Specialization was enabled by default in RC1, and there were a few
> >> bugs reported and subsequently fixed. You can probably workaround the
> >> problem with the compiler option -no-specialization.
> >>
> >> The imminent (?) RC2 release should solve the problem, if not raise a bug.
> >>
> >> -jason
> >>
> >> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto <[hidden email]> wrote:
> >>> Hi,
> >>>
> >>> I'd like to invoke Scala code from Java.
> >>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
> >>> but these codes can't be compiled in Scala 2.8.0.RC1.
> >>>
> >>> Here is the snippet code in TestFunctions.java
> >>>
> >>> // TestFunctions.java
> >>> import scala.*;
> >>>
> >>> public class TestFunctions {
> >>>  static public Function0<Integer> test1 = new Function0<Integer>() {
> >>>      public Integer apply() { return 0; }
> >>>  };
> >>>
> >>>  static public Function0<String> test2 = new Function0<String>() {
> >>>      public String apply() { return "aaaa"; }
> >>>  };
> >>> }
> >>>
> >>>
> >>> Here is the compile error:
> >>>
> >>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> >>> TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
> >>> does not override abstract method apply$mcD$sp() in scala.Function0
> >>>      public Integer apply() { return 0; }
> >>>                     ^
> >>> TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
> >>> does not override abstract method apply$mcD$sp() in scala.Function0
> >>>      public String apply() { return "aaaa"; }
> >>>                    ^
> >>> 2 errors
> >>>
> >>> I have two questions.
> >>>
> >>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> >>> interoperability between Scala and Java changed?
> >>> 2. Are there any hints to modify this compile error?
> >>>
> >>> My environments are the followings:
> >>>
> >>> OS: Mac OSX 10.6.3
> >>> Java:
> >>>  java version "1.6.0_17"
> >>>  Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
> >>>  Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
> >>>
> >>> Scala:
> >>>  Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
> >>>
> >>> Regards,
> >>> K.Okamoto
> >>>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Randall R Schulz-2
In reply to this post by Dennis Haupt-2
On Tuesday May 4 2010, HamsterofDeath wrote:
> what's the difference, except that i can only apply the latter to a
> method which takes "f: => returntype" as a parameter and the first
> one to methods which want "f: () => returntype"?

When you write { doStuff() } as an argument, it evaluates that block and
passes the result to the called method.

When you write () => { doStuff() } you're writing a function literal
whose type is Function1[Unit, Stuff] where Stuff is the result type for
the block containing doStuff().


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Maxime Lévesque

 Also, you can convert a CBN to a Function1 using _ :
 
   def f(z: =>T) = z _ // the return is of type ()=>T

 Max

On Tue, May 4, 2010 at 3:00 PM, Randall R Schulz <[hidden email]> wrote:
On Tuesday May 4 2010, HamsterofDeath wrote:
> what's the difference, except that i can only apply the latter to a
> method which takes "f: => returntype" as a parameter and the first
> one to methods which want "f: () => returntype"?

When you write { doStuff() } as an argument, it evaluates that block and
passes the result to the called method.

When you write () => { doStuff() } you're writing a function literal
whose type is Function1[Unit, Stuff] where Stuff is the result type for
the block containing doStuff().


Randall Schulz

Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Dennis Haupt-2
In reply to this post by Randall R Schulz-2


i assume you meant if i wrote:
val x = () => whatever()
and
val x = whatever()
?

because in both cases, as a parameter it is not evaluated immediately. i
tested it. take a look at HashMap.getOrElseUpdate
the function is "=> B", but is evaluated only if necessary

Randall R Schulz schrieb:

> On Tuesday May 4 2010, HamsterofDeath wrote:
>  
>> what's the difference, except that i can only apply the latter to a
>> method which takes "f: => returntype" as a parameter and the first
>> one to methods which want "f: () => returntype"?
>>    
>
> When you write { doStuff() } as an argument, it evaluates that block and
> passes the result to the called method.
>
> When you write () => { doStuff() } you're writing a function literal
> whose type is Function1[Unit, Stuff] where Stuff is the result type for
> the block containing doStuff().
>
>
> Randall Schulz
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Yukinori NAKATA
In reply to this post by Mark Harrah
On Tue, 4 May 2010 14:58:02 -0400
Mark Harrah <[hidden email]> wrote:

> In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used.  I don't know if it is considered an implementation detail or subject to change, though.

Oh, it's working fine with Scala 2.8.0.RC1.

I hope scala.runtime.AbstractFunctionX could be useful skeletons like
java.util.AbstractList, available for users.

source:
import scala.Function0;
import scala.runtime.AbstractFunction0;
import scala.collection.mutable.Map;
import scala.collection.mutable.LinkedHashMap;

public class TestFunctions {
  static public Function0<Integer> test1 = new AbstractFunction0<Integer>() {
    public Integer apply() {
      return 0;
    }
  };

  static public Function0<String> test2 = new AbstractFunction0<String>() {
    public String apply() {
      return "aaaa";
    }
  };

  public static void main(String[] args) {
    Map<Integer,Integer> map1 =  new LinkedHashMap<Integer,Integer>();
    Map<Integer,String>  map2 =  new LinkedHashMap<Integer,String>();
   
    System.out.printf("test1 = %d%n", map1.getOrElse(0, test1));
    System.out.printf("test2 = %s%n",  map2.getOrElse(0, test2));
  };
}

results:
test1 = 0
test2 = aaaa

--
Yukinori NAKATA <[hidden email]>

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Yukinori NAKATA
Are there any hints to know if it is a implementation detail or not?

On Wed, 05 May 2010 04:51:39 +0900
Yukinori NAKATA <[hidden email]> wrote:

> > In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used.  I don't know if it is considered an implementation detail or subject to change, though.
>
> Oh, it's working fine with Scala 2.8.0.RC1.
>
> I hope scala.runtime.AbstractFunctionX could be useful skeletons like
> java.util.AbstractList, available for users.

Regards,
Yukinori NAKATA <[hidden email]>

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Naftoli Gugenheim
In reply to this post by Dennis Haupt-2
{ doStuff() } is a block expression containing a statement that when executed will call doStuff.
() => { doStuff()  } is a single expression consisting of a function that contains a block expression containing a statement that when executed will call doStuff.

If a method takes a () => T parameter, then you have to pass it a an expression of type () => T.
If a method takes a => T parameter, then you have to pass it an expression of type T. However, behind the scenes that expression will be wrapped in a function, and that function will be invoked whenever the method reads it.

On Tue, May 4, 2010 at 2:46 PM, HamsterofDeath <[hidden email]> wrote:
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?

Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Kazumi Okamoto
In reply to this post by Jason Zaugg
Jason,

Thank you for your reply.

> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)

I tried this solution and it worked properly,but I have also questions.

How do I get the specialization method info of Scala? API documents or
source code?

Regards,
K.Okamoto

2010/5/5 Jason Zaugg <[hidden email]>:

> Oh, I see, that's a tricky problem. It seems that specialized traits
> can't be (easily) extended from Java.
>
> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)
>
>  // scala
>  class MyFunction0[+R] extends Function0[R]
>
>  // java
>  public Function0<String> test2 = new MyFunction0<String>() {
>        public String apply() { return "aaaa"; }
>  };
>
> You can learn more about the internals of specialization from this
> presentation [1].
>
> -jason
>
> [1] http://days2010.scala-lang.org/node/138/151
>
> On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto <[hidden email]> wrote:
>> Jason,
>>
>> Thank you for your reply.
>>
>>> Specialization was enabled by default in RC1, and there were a few
>>> bugs reported and subsequently fixed. You can probably workaround the
>>> problem with the compiler option -no-specialization.
>>
>> Because I want to compile my java code with scala-library.jar by javac,
>> I can't use the scalac compiler option.
>>
>> Regards,
>> K.Okamoto
>>
>> 2010/5/5 Jason Zaugg <[hidden email]>:
>>> Specialization was enabled by default in RC1, and there were a few
>>> bugs reported and subsequently fixed. You can probably workaround the
>>> problem with the compiler option -no-specialization.
>>>
>>> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>>>
>>> -jason
>>>
>>> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I'd like to invoke Scala code from Java.
>>>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>>>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>>>
>>>> Here is the snippet code in TestFunctions.java
>>>>
>>>> // TestFunctions.java
>>>> import scala.*;
>>>>
>>>> public class TestFunctions {
>>>>  static public Function0<Integer> test1 = new Function0<Integer>() {
>>>>      public Integer apply() { return 0; }
>>>>  };
>>>>
>>>>  static public Function0<String> test2 = new Function0<String>() {
>>>>      public String apply() { return "aaaa"; }
>>>>  };
>>>> }
>>>>
>>>>
>>>> Here is the compile error:
>>>>
>>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>>> TestFunctions.java:6: <anonymous TestFunctions$1> is not abstract and
>>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>>      public Integer apply() { return 0; }
>>>>                     ^
>>>> TestFunctions.java:10: <anonymous TestFunctions$2> is not abstract and
>>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>>      public String apply() { return "aaaa"; }
>>>>                    ^
>>>> 2 errors
>>>>
>>>> I have two questions.
>>>>
>>>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>>>> interoperability between Scala and Java changed?
>>>> 2. Are there any hints to modify this compile error?
>>>>
>>>> My environments are the followings:
>>>>
>>>> OS: Mac OSX 10.6.3
>>>> Java:
>>>>  java version "1.6.0_17"
>>>>  Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>>>  Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>>>
>>>> Scala:
>>>>  Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>>>
>>>> Regards,
>>>> K.Okamoto
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Jason Zaugg
Looking at the source code is your best bet at the moment, as Scaladoc
doesn't [1] show
 - annotations of trait type parameters
 - FunctionN, where N != 1

If you look at the source for Function1 [2], you can see the
@specialized annotation on the type parameters. I've grepped the
currentl list of specialiazed types and methods below.

-jason

 [1] http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html
 [2] https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src///library/scala/Function1.scala

scala/Function0.scala:trait Function0[@specialized +R] extends AnyRef { self =>
scala/Function1.scala:trait Function1[@specialized(scala.Int,
scala.Long, scala.Float, scala.Double) -T1,
scala/Function2.scala:trait Function2[@specialized(scala.Int,
scala.Long, scala.Double) -T1, @specialized
scala/Product1.scala:trait Product1[@specialized(Int, Long, Double)
+T1] extends Product {
scala/Product2.scala:trait Product2[@specialized(Int, Long, Double)
+T1, @specialized(Int, Long, Double)
scala/Tuple1.scala:case class Tuple1[@specialized(Int, Long, Double) +T1](_1:T1)
scala/Tuple2.scala:case class Tuple2[@specialized(Int, Long, Double)
+T1, @specialized(Int, Long, Double)
scala/collection/immutable/Range.scala:  override def
foreach[@specialized(Unit) U](f: Int => U) {
scala/collection/immutable/Range.scala:    override final def
foreach[@specialized(Unit) U](f: Int => U)
scala/runtime/AbstractFunction0.scala:abstract class
AbstractFunction0[@specialized +R] extends Function0
scala/runtime/AbstractFunction1.scala:abstract class
AbstractFunction1[@specialized(scala.Int, scala.Long
scala/runtime/AbstractFunction2.scala:abstract class
AbstractFunction2[@specialized(scala.Int, scala.Long
scala/runtime/AnyValCompanion.scala: *     class
Tuple1[@specialized(Unit, Int, Double) T]

On Wed, May 5, 2010 at 12:42 AM, Kazumi Okamoto <[hidden email]> wrote:

> Jason,
>
> Thank you for your reply.
>
>> You could make a scala class to bridge between the abstract,
>> specialized methods on the interface Function0 and your java subclass.
>> The scala compiler will generate default implementations of the
>> specialised versions of apply. (e.g. apply$mcD$sp)
>
> I tried this solution and it worked properly,but I have also questions.
>
> How do I get the specialization method info of Scala? API documents or
> source code?
>
> Regards,
> K.Okamoto
Reply | Threaded
Open this post in threaded view
|

Re: Problem: Java and Scala interoperability in 2.8.0.RC1

Yukinori NAKATA
In reply to this post by Yukinori NAKATA
Hello,

> In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be
> used. I don't know if it is considered an implementation detail or subject
> to change, though.

I found the discussion in scala-internals.
It says that users are granted to use AbstractFunctionX for general use.

Improvements for FunctionN
http://www.scala-lang.org/node/4338

Paul Phillips wrote:
> And I forgot to ask about naming: on the one hand they could go into
> scala.runtime.*, but that sends a message they're not for general use.
> Which, granted, might be the right message to send at this stage. If I
> put them in runtime maybe they should be called AnonFun0-22 or something
> along those lines.

Thanks for making discussions open.

Regards,
Yukinori NAKATA <[hidden email]>

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Steven Shaw-2
In reply to this post by Luc Duponcheel
On 5 May 2010 04:56, Luc Duponcheel <[hidden email]> wrote:
by the way: I aways found it strange that Scala supports
functions with zero parameter lists but does not support
function values with zero parameter lists (maybe making
CBV parameters unnecessary (?))

Do you mean that you can call a function defined with no arguments by just using the function's name? e.g.

scala> def f = 6  
f: Int

scala> f
res17: Int = 6

scala> f()
<console>:7: error: f of type Int does not take parameters
       f()
        ^

scala> val v = f _
v: () => Int = <function0>

scala> v
res19: () => Int = <function0>

scala> v()
res20: Int = 6 

I reckon the call-by-value is more to do with the usage-side rather than the implementation-side. However, with a very terse syntax for blocks/lambdas, the need for CBV is reduced. Thinking of Smalltalk style syntax:

  isDone ifTrue: [ do1 ] ifFalse: [ do2 ]

CBV is still pretty neat though in my book.
Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Luc Duponcheel
What I mean is the following:
functions having one empty parameter list
and function values having one empty parameter list
work nice together:

scala> def function() = "function"
function: ()java.lang.String

scala> function()
res0: java.lang.String = function

scala> var functionValue = () => "functionValue"
functionValue: () => java.lang.String = <function0>

scala> functionValue()
res1: java.lang.String = functionValue

scala> functionValue = function
functionValue: () => java.lang.String = <function0>

scala> functionValue()
res2: java.lang.String = function


Why not the same for
functions having zero parameter lists (exist in Scala)
and function values having zero parameter lists (do not exist in Scala)

scala> def function = "function"
function: java.lang.String

scala> function
res3: java.lang.String = function

scala> var functionValue = => "functionValue"
<console>:1: error: illegal start of simple expression
       var functionValue = => "functionValue"

introducing function values with zero parameter lists
could, maybe, replace call by name

Luc

On Wed, May 5, 2010 at 11:54 PM, Steven Shaw <[hidden email]> wrote:
On 5 May 2010 04:56, Luc Duponcheel <[hidden email]> wrote:
by the way: I aways found it strange that Scala supports
functions with zero parameter lists but does not support
function values with zero parameter lists (maybe making
CBV parameters unnecessary (?))

Do you mean that you can call a function defined with no arguments by just using the function's name? e.g.

scala> def f = 6  
f: Int

scala> f
res17: Int = 6

scala> f()
<console>:7: error: f of type Int does not take parameters
       f()
        ^

scala> val v = f _
v: () => Int = <function0>

scala> v
res19: () => Int = <function0>

scala> v()
res20: Int = 6 

I reckon the call-by-value is more to do with the usage-side rather than the implementation-side. However, with a very terse syntax for blocks/lambdas, the need for CBV is reduced. Thinking of Smalltalk style syntax:

  isDone ifTrue: [ do1 ] ifFalse: [ do2 ]

CBV is still pretty neat though in my book.



--
  __~O
 -\ <,
(*)/ (*)

reality goes far beyond imagination

Reply | Threaded
Open this post in threaded view
|

Re: difference between "() => { doStuff() }" and "{ doStuff()}"

Randall R Schulz-2
On Thursday May 6 2010, Luc Duponcheel wrote:

> What I mean is the following:
> functions having one empty parameter list
> and function values having one empty parameter list
> work nice together:
>
> ...
>
> Why not the same for
> functions having zero parameter lists (exist in Scala)
> and function values having zero parameter lists (do not exist in
> Scala)
>
> ...
>
> introducing function values with zero parameter lists
> could, maybe, replace call by name

How would you refer to such a function value (to store it, pass it,
etc.) without invoking it?


> Luc


Randall Schulz
12