Problem: Java and Scala interoperability in 2.8.0.RC1

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 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 test1 = new Function0() {
>      public Integer apply() { return 0; }
>  };
>
>  static public Function0 test2 = new Function0() {
>      public String apply() { return "aaaa"; }
>  };
> }
>
>
> Here is the compile error:
>
> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> TestFunctions.java:6: is not abstract and
> does not override abstract method apply$mcD$sp() in scala.Function0
>      public Integer apply() { return 0; }
>                     ^
> TestFunctions.java:10: 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
>

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 :
> 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 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 test1 = new Function0() {
>>      public Integer apply() { return 0; }
>>  };
>>
>>  static public Function0 test2 = new Function0() {
>>      public String apply() { return "aaaa"; }
>>  };
>> }
>>
>>
>> Here is the compile error:
>>
>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>> TestFunctions.java:6: is not abstract and
>> does not override abstract method apply$mcD$sp() in scala.Function0
>>      public Integer apply() { return 0; }
>>                     ^
>> TestFunctions.java:10: 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
>>
>

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 test2 = new MyFunction0() {
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 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 :
>> 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 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 test1 = new Function0() {
>>>      public Integer apply() { return 0; }
>>>  };
>>>
>>>  static public Function0 test2 = new Function0() {
>>>      public String apply() { return "aaaa"; }
>>>  };
>>> }
>>>
>>>
>>> Here is the compile error:
>>>
>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>> TestFunctions.java:6: is not abstract and
>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>      public Integer apply() { return 0; }
>>>                     ^
>>> TestFunctions.java:10: 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
>>>
>>
>

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 test1 = new Function0() {
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 test2 = new Function0() {
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,

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"?

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 <h-star@gmx.de> 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

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 test2 = new MyFunction0() {
> 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 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 :
> >> 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 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 test1 = new Function0() {
> >>> public Integer apply() { return 0; }
> >>> };
> >>>
> >>> static public Function0 test2 = new Function0() {
> >>> public String apply() { return "aaaa"; }
> >>> };
> >>> }
> >>>
> >>>
> >>> Here is the compile error:
> >>>
> >>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> >>> TestFunctions.java:6: is not abstract and
> >>> does not override abstract method apply$mcD$sp() in scala.Function0
> >>> public Integer apply() { return 0; }
> >>> ^
> >>> TestFunctions.java:10: 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
> >>>
> >>
> >
>
>

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

 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 <rschulz@sonic.net> 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

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

On Tue, 4 May 2010 14:58:02 -0400
Mark Harrah 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 test1 = new AbstractFunction0() {
public Integer apply() {
return 0;
}
};

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

public static void main(String[] args) {
Map map1 = new LinkedHashMap();
Map map2 = new LinkedHashMap();

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

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

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

{ 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 <h-star@gmx.de> 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"?

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 :
> 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 test2 = new MyFunction0() {
>        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 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 :
>>> 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 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 test1 = new Function0() {
>>>>      public Integer apply() { return 0; }
>>>>  };
>>>>
>>>>  static public Function0 test2 = new Function0() {
>>>>      public String apply() { return "aaaa"; }
>>>>  };
>>>> }
>>>>
>>>>
>>>> Here is the compile error:
>>>>
>>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>>> TestFunctions.java:6: is not abstract and
>>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>>      public Integer apply() { return 0; }
>>>>                     ^
>>>> TestFunctions.java:10: 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
>>>>
>>>
>>
>

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/...
[2] https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src///library/sca...

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

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

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

On 5 May 2010 04:56, Luc Duponcheel <luc.duponcheel@gmail.com> 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> fres17: Int = 6
scala> f()<console>:7: error: f of type Int does not take parameters       f()        ^
scala> val v = f _v: () => Int = <function0>
scala> vres19: () => 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.

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 <steshaw@gmail.com> wrote:

On 5 May 2010 04:56, Luc Duponcheel <luc.duponcheel@gmail.com> 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> fres17: Int = 6
scala> f()<console>:7: error: f of type Int does not take parameters       f()        ^
scala> val v = f _v: () => Int = <function0>
scala> vres19: () => 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

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

consider

scala> val fooArg = () => "fooArg"
fooArg: () => java.lang.String = <function0>

scala> def barFun(fooParam: () => java.lang.String) = fooParam()
barFun: (fooParam: () => java.lang.String)java.lang.String

scala> barFun(fooArg)
res0: java.lang.String = fooArg

well, I would like to do something like

scala> val fooArg = => "fooArg"
fooArg: => java.lang.String = <function???>

scala> def barFun(fooParam: => java.lang.String) = fooParam
barFun: (fooParam: => java.lang.String)java.lang.String

scala> barFun(fooArg)
res0: java.lang.String = fooArg


in other words: I would use the current CBN syntax


or am I missing something?


Luc


On Thu, May 6, 2010 at 3:42 PM, Randall R Schulz <rschulz@sonic.net> wrote:

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

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

reality goes far beyond imagination

On Thursday May 6 2010, you wrote:
> ...
>
> or am I missing something?

If f is a val whose type is one of these zero-arg-list functions, how do
you distinguish invoking that function from dereferencing f to get the
function itself? It seems strictly ambiguous to me.

> Luc

Randall Schulz

On Thu, May 06, 2010 at 08:21:21AM -0700, Randall R Schulz wrote:
> If f is a val whose type is one of these zero-arg-list functions, how
> do you distinguish invoking that function from dereferencing f to get
> the function itself? It seems strictly ambiguous to me.

The identical issue already exists with 1-empty-arg-list functions.

scala> def f() = 5
f: ()Int

scala> println(f)
5

And you'd distinguish it the same way.

scala> println(() => f)