newbie questions

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

newbie questions

62945

- where is scala.Int (and other numeric types in the API) ?
- if "var a" is scala.Int and "var b" java.lang.Integer is there a way to assign "a = b" ("b = a" works fine in the interpreter) ? my newbie understanding would say "="  is a method taking some java.lang.Integer as argument.
- beg you people to explain synchronization/concurrency in greater detail. There is a API specific to scala, fine. The docs say synchronized is a method of Any/AnyRef (?) ... confusing since the syntax goes " : synchronized { " ... its a use of inheritance maybe


Reply | Threaded
Open this post in threaded view
|

Re: newbie questions

Nikolay Mihaylov
Hello

On Sun, 2006-04-09 at 19:40 -0300, 62945 wrote:
> - where is scala.Int (and other numeric types in the API) ?

They are only in the compiler's imagination. Since they represent the
primitive JVM types they cannot, strictly speaking, have an interface.
We used to have a bunch of Java (or rather, Pico) files that were only
used to specify the operations allowed for them but not any behaviour
since they are never instantiated. Last week however we removed them
from the repository and let the compiler generate them internally. Mind
you, they were never present in the Scala API documentation because it
is generated only from Scala sources.

>  - if "var a" is scala.Int and "var b" java.lang.Integer is there a way
>  to assign  "a = b" ("b = a" works fine in the interpreter) ? my newbie
>  understanding would say "="  is a method taking some java.lang.Integer
>  as argument.

scala.Int and java.lang.Integer are incompatible, that is they live in
different branches of the class hierarchy. However, for Java
compatibility's sake, we introduced implicit conversions (that are
silently applied by the compiler under the right circumstances) from the
scala.* value types to their java.lang correspondents. Take a look at
scala/Predef.scala for more details. So when you wrote 'b = a' what the
compiler generates is 'b = Predef.int2Integer(a)'. This is mostly useful
when you have some legacy Java code that absolutely expects
java.lang.Integer or the like. Scala has its own box classes and
boxing/unboxing is done automatically even when it interfaces with Java
code.

>  - beg you people to explain synchronization/concurrency
>   in greater detail. There is a API specific to scala, fine. The docs
>   say synchronized is a method of Any/AnyRef (?) ... confusing since
>  the  syntax goes " : synchronized { " ... its a use of inheritance
>  maybe    

Having 'synchronized' as a method of AnyRef lets us implement it without
special syntax. Whenever you write 'synchronized {...}' you get
'this.synchronized {...}', which I guess is what you mean by inheritance
in your mail. Also 'someObj synchronized {...}' needs no tranformation
and is, obviously, equivalent to Java's 'synchronized (someObj) {...}'.
Of course, in reality there's no such 'synchronized' method so the
compiler intercepts every call to it and generates the appropriate code
to implement it. Everything else (including thread creation or
signalling) is "as in Java."

Doesn't this sound reasonable?

Nikolay

Reply | Threaded
Open this post in threaded view
|

Re: newbie questions

62945
In reply to this post by 62945
Hi

> > - where is scala.Int (and other numeric types in the API) ?
>
> They are only in the compiler's imagination. Since they represent the
> primitive JVM types they cannot, strictly speaking, have an interface.

to me (the user) they seem quite real. Perhaps the interface isn't explicit, but they (numbers) interact with other objects though some interface, i guess.

you said they are primitive ... if they are already there where is the bridge to move things back and forth ?

> > - if "var a" is scala.Int and "var b" java.lang.Integer is there a way
> > to assign "a = b" ("b = a" works fine in the interpreter) ? my newbie
> > understanding would say "=" is a method taking some java.lang.Integer
> > as argument.
>
> scala.Int and java.lang.Integer are incompatible, that is they live in
> different branches of the class hierarchy. However, for Java
> compatibility's sake, we introduced implicit conversions (that are
> silently applied by the compiler under the right circumstances) from the
> scala.* value types to their java.lang correspondents. Take a look at
> scala/Predef.scala for more details. So when you wrote 'b = a' what the
> compiler generates is 'b = Predef.int2Integer(a)'. This is mostly useful
> when you have some legacy Java code that absolutely expects
> java.lang.Integer or the like. Scala has its own box classes and
> boxing/unboxing is done automatically even when it interfaces with Java
> code.

ok but you didn't answer the question. what is the way to bring java numbers into scala ? as a newbie the only thing i came up with is clumsy:

val z = scala.runtime.compat.Platform
a = z.parseInt(b.toString())

scala.BigInt is there but the other stuff is missing ...

> Having 'synchronized' as a method of AnyRef lets us implement it without
> special syntax. Whenever you write 'synchronized {...}' you get
> 'this.synchronized {...}', which I guess is what you mean by inheritance
> in your mail. Also 'someObj synchronized {...}' needs no tranformation
> and is, obviously, equivalent to Java's 'synchronized (someObj) {...}'.
> Of course, in reality there's no such 'synchronized' method so the
> compiler intercepts every call to it and generates the appropriate code
> to implement it. Everything else (including thread creation or
> signalling) is "as in Java."

understood. be kind to bring this info to the docs, other people/newbies will welcome as well

(Nikolay thanks for your detailed support)

Reply | Threaded
Open this post in threaded view
|

Re: newbie questions

Nikolay Mihaylov
Hi again

On Mon, 2006-04-10 at 16:25 -0300, 62945 wrote:
> > > - where is scala.Int (and other numeric types in the API) ?
> >
> > They are only in the compiler's imagination. Since they represent the
> > primitive JVM types they cannot, strictly speaking, have an interface.
>
> to me (the user) they seem quite real. Perhaps the interface isn't
>  explicit, but they (numbers) interact with other objects though some
>  interface, i guess.

I'm not sure I understand your statement so please be lenient if I'm not
addressing it properly. The interface of a class specifies how you as a
programmer (or, in fact, the code you write) interact with the object.
The problem is, primitive types do not have explicit interface. However,
Scala goes to great lengths to ensure a uniform type space, that is
"every value is an object." For the primitive (or value) types the idea
is that you don't care about their special implementation properties.
>From a Scala perspective they are just objects. And they often are (in
their boxed form). The compiler will use the most efficient
represenation given the static type information it can obtain/infer from
your code.

In short, you should treat numbers as, well, numbers. Whatever you can
do with the primitive types in Java you can do it in Scala. You have the
same arithmetic and logical operations expressed with the good old Java
syntax. You have the same widening conversions. You still use typecasts
for the narrowing conversion, e.g.

  val b: Byte = 1.asInstanceOf[Byte]

Ok, you can do a bit better because such conversions are way too
verbose. All numerical types can be converted to every other numerical
type with an appropriate to* parameterless method

  val b: Byte = 1.toByte

In fact, they are both translated to the same thing (the latter one).


> you said they are primitive ... if they are already there where is the
>  bridge to move things back and forth ?

Maybe you are talking boxing/unboxing. This need not concern you,
because it's an implementation detail and changes nothing for the
programmer. The compiler does what is necessary to preserve the "every
value is an object" illusion while using the most efficient
representation where possible. For instance, you can pass a scala.Int
(that is Java 'int') to a method that accepts a parameter of type
scala.Any (java.lang.Object in the method declaration  in Java) and the
integer will automatically be boxed in a scala.runtime.BoxedInt object.
And you can cast it back if you put a scala.Int there. For instance you
can use the Java collection classes (although we would rather have you
use the Scala collection classes)

  val list: java.util.List
  list.add(13)
  Console.println(list.get(0).asInstanceOf[Int])

You can also use the generefied versions of the Java collection classes
with the '-Xgenerics' option of the Scala compiler.

> ok but you didn't answer the question. what is the way to bring java
>  numbers into scala ? as a newbie the only thing i came up with is
>  clumsy:
>
> val z = scala.runtime.compat.Platform
> a = z.parseInt(b.toString())
>
> scala.BigInt is there but the other stuff is missing ...

Right. I tried to explain why you shouldn't ask this question. But, of
course, you might have Java code that gives you java.lang.Integer
objects, say a collection that has been populated by Java code and you
want your integers back from Scala. But this is not a Scala question.
The answer is in the interface of java.lang.Integer and seems to be in
the intValue() method. So you should write

  a = b.intValue()

If you use this often you better define implicit conversion from the
Java box types to Scala numerical types like (the name of the mehod
doesn't matter)

  implicit def integer2Int(x: java.lang.Integer): Int = x.intValue()

and make sure it is visible at the point of use without qualification.

Nikolay

Reply | Threaded
Open this post in threaded view
|

Re: newbie questions

Lex Spoon
Hmm, it is true that the value types have a number of methods that the
respond to.  The implementation maps all this down to primitive
operations on the JVM, but that is semantically invisible.

The methods that are available are nothing special -- just things like
+, -, *, and / .  I guess it would be nice to have these listed
somewhere....


-Lex