Question about ScalaObject

Hi,

I think I have asked this question before but I am still confused with the usage of scala.ScalaObject. In Scala 2.7.5 version it used to have a $tag method

public interface scala.ScalaObject{
    public abstract int $tag()       throws java.rmi.RemoteException;
}

But in Scala 2.8 it is just an empty interface

public interface scala.ScalaObject{
}

Any explanation will be helpful.

Nilanjan

On Wed, Mar 24, 2010 at 3:45 AM, Nilanjan Raychaudhuri <nraychaudhuri@gmail.com> wrote:

Hi,

I think I have asked this question before but I am still confused with the usage of scala.ScalaObject. In Scala 2.7.5 version it used to have a $tag method

public interface scala.ScalaObject{
    public abstract int $tag()       throws java.rmi.RemoteException;
}

But in Scala 2.8 it is just an empty interface

public interface scala.ScalaObject{
}

Any explanation will be helpful.

Like all methods with $'s, $tag was only meant for internal use. It played a role in optimizing pattern matching, but since it was not very effective we dropped it.

 -- Martin

In the SLS (I have the version 2.7 draft dated October 28, 2009), in
6.25.3 Overloading Resolution, it uses the adjective "parameterized"
referring to methods.  Every other use of "parameterized" in the
document (except for one in the Changes appendix) is concerned with
parameterized types.

Since the phrase "parameterized method" is never defined, is the
reader to assume that parameterized methods are simply methods
declared or defined with a parameter list (i.e. the ParamClause
nonterminal in the grammar)?

If that is so, then I find the rules (the four bullets in 6.25.3 that
define "as specific as") for overloading resolution (in the context of
a function application) very hard to understand, as the 3rd and 4th
bullets discuss overloaded members that may be other than
parameterized methods or polymorphic methods.  The only such members I
can think of are parameterless methods (mentioned first in 3.3.1),
which would only be relevant if the function application being
resolved had an empty argument list.

In the example given (Example 6.25.1),

  class A extends B {}
  def f(x: B, y: B) = . . .
  def f(x: A, y: B) = . . .
  val a: A
  val b: B


the function application f(a,a) has two arguments, and there are no
polymorphic methods in sight.  So, the only bullet that seems relevant
is the first.  It says:

   A parameterized method of type (Ts)U is as specific as some other
   member of type S if S is applicable to arguments (ps) of types Ts.

The Ts represent the "vector of types obtained by typing each argument
with an undefined expected type".  In the example for f(a,a), Ts would
be (A,A).  But this rule seems to only be relevant if there is an exact
match of all the argument types with the parameter types of a
candidate method.

Neither method in the example has the type (A,A)U.  [See 3.3.1 to see
how method types are represented].  So I don't see how the call gets
resolved, using the rules as given.

What am I missing?

--
Steve

On Wed, Mar 24, 2010 at 11:55:17AM -0700, Steve Preston wrote:
> Since the phrase "parameterized method" is never defined, is the
> reader to assume that parameterized methods are simply methods
> declared or defined with a parameter list (i.e. the ParamClause
> nonterminal in the grammar)?

It would seem so. I googled my way to this:

http://www.scala-lang.org/node/121

"Methods in Scala can be parameterized with both values and types. Like
on the class level, value parameters are enclosed in a pair of
parentheses, while type parameters are declared within a pair of
brackets."

I'd have to look harder than I have time for at this second to take a
stab at the meat of your question. But you should really work from an
up to date specification before asking questions:

http://www.scala-lang.org/node/212/pdfs

Thanks for the response.So ScalaObject mixin is not used any more?

Nilanjan

On Wed, Mar 24, 2010 at 1:02 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Mar 24, 2010 at 3:45 AM, Nilanjan Raychaudhuri <nraychaudhuri@gmail.com> wrote:

Hi,

I think I have asked this question before but I am still confused with the usage of scala.ScalaObject. In Scala 2.7.5 version it used to have a $tag method

public interface scala.ScalaObject{
    public abstract int $tag()       throws java.rmi.RemoteException;
}

But in Scala 2.8 it is just an empty interface

public interface scala.ScalaObject{
}

Any explanation will be helpful.

Like all methods with $'s, $tag was only meant for internal use. It played a role in optimizing pattern matching, but since it was not very effective we dropped it.

 -- Martin

Hello,

Every Scala object extends ScalaObject. This trait is empty. What this means is that even if I write code that does not use any of the objects from the scala subpackages, I still have a dependency on scala-library.jar.

Can this automatic extending of ScalaObject be disabled/removed?

Thank you,

Ittay

You can never be sure that the final bytecode won't contain references to something in scala-library.For example.. pattern matching on case classes is delegated to a class there.

In normal use, you should have scala-library on the classpath at deployment time.
In a size-limited scenario (android, mobile, or other embedded environment), you can also use proguard or yGuard to combine the library with your project and eliminate all dead code.


On 20 June 2010 10:13, Ittay Dror <ittay.dror@gmail.com> wrote:

Hello,


Every Scala object extends ScalaObject. This trait is empty. What this means is that even if I write code that does not use any of the objects from the scala subpackages, I still have a dependency on scala-library.jar.


Can this automatic extending of ScalaObject be disabled/removed?


Thank you,

Ittay

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hi,

 

This code doesn’t compile. (Scala 2.8 trunk)

object Main extends Application{

  def converter(p: Byte) {}

  def converter(p: Boolean) {} //commented this method remove compilation error

  def converter(x: Int, p: Boolean) {}

  converter(123)

}

 

So it’s impossible to use overloading resolution with weak conformance, if there are same numbers of arguments. Same thing with Unit type (conversion to Unit type).

I can’t find anything about this in specification, but as I understand, it should compile according to spec. Maybe somebody knows some info about weak conformance, and implicit conversion to Unit type.

 

Best regards,

Alexander Podkhalyuzin.

Hi Alexander,

On Tuesday, June 22, 2010 07:27:22 am Alexander Podkhalyuzin wrote:
> Hi,
>
> This code doesn't compile. (Scala 2.8 trunk)
>
> object Main extends Application{
>
> def converter(p: Byte) {}
>
> def converter(p: Boolean) {} //commented this method remove compilation
> error
>
> def converter(x: Int, p: Boolean) {}
>
> converter(123)
>
> }
>
> So it's impossible to use overloading resolution with weak conformance, if
> there are same numbers of arguments. Same thing with Unit type (conversion
> to Unit type).

I don't think this is related to weak conformance. Weak conformance is new in
2.8 and the code above gives a compile error in 2.7.7 as well.

> I can't find anything about this in specification, but as I understand, it
> should compile according to spec. Maybe somebody knows some info about weak
> conformance, and implicit conversion to Unit type.

See 1.3.1 Integer Literals, where it says:

"However, if the expected type pt of a literal in an expression is either
Byte, Short, or Char and the integer number fits in the numeric range defined by
the type, then the number is converted to type pt and the literal's type is
pt."

In 6.26.3 Overloading Resolution, it says that when there is more than one
alternative that has the same arity, each argument is typed with an undefined
expected type and it proceeds from there. As I understand this, there is no
expected type that can be used for numeric literal narrowing, value discarding
(conversion to unit), or view application.

-Mark

> Best regards,
>
> Alexander Podkhalyuzin.

Hi, Mark,

So the main question what exactly means Expected Type?

It's about anonymous functions:

If the expected type of the anonymous function is of the form
scala.FunctionN, the expected type of e is R and the type Ti
of any of the parameters xi can be omitted.

If expected type is undefined for overloading resolution, when we have few alternatives with same arity, then why this code compiles:

object Main extends Application {
def converter (x: Int => Int) = 1
def converter (x: String) = 3

converter(_ + 1)
}

On the other hand this code doesn’t compile:

object Main extends Application {
def converter(p: Byte) = 4
def converter(p: String) = 2
converter(34)
}

As I see, it has same idea. Here we have literal narrowing.

Best regards,
Alexander Podkhalyuzin.

-----Original Message-----
From: Mark Harrah [mailto:harrah@bu.edu]
Sent: Tuesday, June 22, 2010 6:08 PM
To: scala-user@listes.epfl.ch
Subject: Re: [scala-user] Overloading resolution

Hi Alexander,

On Tuesday, June 22, 2010 07:27:22 am Alexander Podkhalyuzin wrote:
> Hi,
>
> This code doesn't compile. (Scala 2.8 trunk)
>
> object Main extends Application{
>
> def converter(p: Byte) {}
>
> def converter(p: Boolean) {} //commented this method remove compilation
> error
>
> def converter(x: Int, p: Boolean) {}
>
> converter(123)
>
> }
>
> So it's impossible to use overloading resolution with weak conformance, if
> there are same numbers of arguments. Same thing with Unit type (conversion
> to Unit type).

I don't think this is related to weak conformance. Weak conformance is new in
2.8 and the code above gives a compile error in 2.7.7 as well.

> I can't find anything about this in specification, but as I understand, it
> should compile according to spec. Maybe somebody knows some info about weak
> conformance, and implicit conversion to Unit type.

See 1.3.1 Integer Literals, where it says:

"However, if the expected type pt of a literal in an expression is either
Byte, Short, or Char and the integer number fits in the numeric range defined by
the type, then the number is converted to type pt and the literal's type is
pt."

In 6.26.3 Overloading Resolution, it says that when there is more than one
alternative that has the same arity, each argument is typed with an undefined
expected type and it proceeds from there. As I understand this, there is no
expected type that can be used for numeric literal narrowing, value discarding
(conversion to unit), or view application.

-Mark

> Best regards,
>
> Alexander Podkhalyuzin.