Why <: and not <=: ?

If I understand typeclass with an upper boundery well then:

A <: B

means

A is a subtype of B or B itself (so B is inclusive)

Wouldn't

A<=: B

be more intuitive (I think the mathematical notation is : ∇t ⊆ τ. t →
t where t is A and τ is B  (hopefully the unicode characters are
encoded well otherwise there is some mojibake in this post))

Re: Why <: and not <=: ?

For loop causing "error: type mismatch;"

Hi,

I'm a beginner at programming in Scala so it may be a mistake from me
(in that case, I apologize) but could someone explain the below?

I've tried a few things, less "inlining", different indentation,
ranges instead of "2 to maxValue toList" and vice versa, even
different implementation, but I'm just stuck at the moment.
Especially since I thought the way I declared the type returned was
explicit:
     def primes(maxValue: Int): List[Int] = { ... }
and since the for loop works just fine outside of the method.

Cheers,

Marc.

Works fine:
    scala> val maxValue = 30
    maxValue: Int = 30

    scala>       var candidates = List.range(2, maxValue+1)
    candidates: List[Int] = List(2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
30)

    scala>       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
         |         candidates = candidates.filter(j => (j == i) || (j
% i != 0)) toList

    scala> candidates
    res15: List[Int] = List(2, 3, 5, 7, 11, 13, 17, 19, 23, 29)

Doesn't work:
    scala>   def primes(maxValue: Int): List[Int] = {
         |     if (maxValue < 2) Nil
         |     else {
         |       var candidates = List.range(2, maxValue+1)
         |       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
         |         candidates = candidates.filter(j => (j == i) || (j
% i != 0)) toList
         |       candidates
         |     }
         |   }
    <console>:15: error: type mismatch;
     found   : List[Int]
     required: Int
                 candidates
                 ^
    <console>:13: error: type mismatch;
     found   : Unit
     required: List[Int]
                 for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))

Maven also complain about the same, so I guess it's not proper to the
way the console compiles on demand:
[ERROR] /Volumes/DATA/tech/workspace/ML-Scala/src/main/scala/org/
marccarre/ml/scala/math/Math.scala:33: error: type mismatch;
[INFO]  found   : List[Int]
[INFO]  required: Int
[INFO]       candidates
[INFO]       ^
[ERROR] /Volumes/DATA/tech/workspace/ML-Scala/src/main/scala/org/
marccarre/ml/scala/math/Math.scala:31: error: type mismatch;
[INFO]  found   : Unit
[INFO]  required: List[Int]
[INFO]       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
[INFO]              ^
[ERROR] two errors found

Re: Abridged summary of scala-language <at> googlegroups.com - 1 Message in 1 Topic

Re: For loop causing "error: type mismatch;"

Hi,

I think you have a problem with semicolon inference.

The following is parsed wrong, because of your (superfluous) call to toList.

for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
  candidates = candidates.filter(j => (j == i) || (j % i != 0)) toList
candidates

toList is nullary, but during semicolon inference Scala doesn't know
that yet and parses the code as if toList was unary:

for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
  candidates = candidates.filter(j => (j == i) || (j % i !=
0)).toList(candidates)

You have multiple choices here: use braces for the for body, use a
semicolon, remove the toList call or insert a blank line.

I would recommend to omit the call to toList, as it serves no purpose
anyway, and additionally put the for body in braces (personal
preference). The following compiles fine:

def primes(maxValue: Int): List[Int] = {
  if (maxValue < 2)
    Nil
  else {
    var candidates = List.range(2, maxValue + 1)
    for (i <- 2 to scala.math.sqrt(maxValue).toInt + 1) {
      candidates = candidates.filter(j => (j == i) || (j % i != 0))
    }
    candidates
  }
}

Also, you might consider using foldLeft instead of the for
comprehension, for a more functional approach.

Regards,
Rüdiger

2011/7/3 Marc CARRÉ <carre.marc <at> gmail.com>:
> Hi,
>
> I'm a beginner at programming in Scala so it may be a mistake from me
> (in that case, I apologize) but could someone explain the below?
>
> I've tried a few things, less "inlining", different indentation,
> ranges instead of "2 to maxValue toList" and vice versa, even
> different implementation, but I'm just stuck at the moment.
> Especially since I thought the way I declared the type returned was
> explicit:
>     def primes(maxValue: Int): List[Int] = { ... }
> and since the for loop works just fine outside of the method.
>
> Cheers,
>
> Marc.
>
>
> Works fine:
>    scala> val maxValue = 30
>    maxValue: Int = 30
>
>    scala>       var candidates = List.range(2, maxValue+1)
>    candidates: List[Int] = List(2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
> 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
> 30)
>
>    scala>       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
>         |         candidates = candidates.filter(j => (j == i) || (j
> % i != 0)) toList
>
>    scala> candidates
>    res15: List[Int] = List(2, 3, 5, 7, 11, 13, 17, 19, 23, 29)
>
> Doesn't work:
>    scala>   def primes(maxValue: Int): List[Int] = {
>         |     if (maxValue < 2) Nil
>         |     else {
>         |       var candidates = List.range(2, maxValue+1)
>         |       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
>         |         candidates = candidates.filter(j => (j == i) || (j
> % i != 0)) toList
>         |       candidates
>         |     }
>         |   }
>    <console>:15: error: type mismatch;
>     found   : List[Int]
>     required: Int
>                 candidates
>                 ^
>    <console>:13: error: type mismatch;
>     found   : Unit
>     required: List[Int]
>                 for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
>
> Maven also complain about the same, so I guess it's not proper to the
> way the console compiles on demand:
> [ERROR] /Volumes/DATA/tech/workspace/ML-Scala/src/main/scala/org/
> marccarre/ml/scala/math/Math.scala:33: error: type mismatch;
> [INFO]  found   : List[Int]
> [INFO]  required: Int
> [INFO]       candidates
> [INFO]       ^
> [ERROR] /Volumes/DATA/tech/workspace/ML-Scala/src/main/scala/org/
> marccarre/ml/scala/math/Math.scala:31: error: type mismatch;
> [INFO]  found   : Unit
> [INFO]  required: List[Int]
> [INFO]       for (i <- (2 to scala.math.sqrt(maxValue).toInt + 1))
> [INFO]              ^
> [ERROR] two errors found
>

Re: Why <: and not <=: ?

Thanks, Donna.

Parallel Collections fail

Hi all,

this weekend, I was stumped that abstracting over parallel and
sequential collections with the generic GenSeq etc types is completely
broken. See this example:

val items = (0 to 10000)
val parItems: collection.GenSeq[Int] = if (true) items.par else items.seq
parItems.map {
 _ => Thread.currentThread.getName
}

ParVector(Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
Thread-107, Threa...

In summary, an operation is never executed in parallel if the static
type of the collection is not a parallel one which is defeating the
purpose of the generic collections construction completely. This is,
because dynamic dispatch - as I would have expected it - is
circumvented by deciding if something should be run in parallel by the
instance of the CanBuildFrom which is chosen statically instead of at
runtime.

I find this a bit upsetting since we had quite a discussion months ago
about the design of the parallel collections and it seems no one
(including me) did actually test that the resulting implementation did
what was promised.

Another problem here is that you can't write

val parItems = if (true) items.par else items.seq

without the type annotation, because type inference fails badly here
(though that seems to be fixed in trunk already).

--

-- 
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Re: Parallel Collections fail

I believe this is due to the fact that the `map` in `ParIterableLike`
checks whether the builder factory is parallel, instead of
instantiating the builder and checking if the builder is parallel.

I'll fix this.

Cheers,
Alex

On Jul 4, 1:18 pm, Johannes Rudolph <johannes.rudo... <at> googlemail.com>
wrote:
> Hi all,
>
> this weekend, I was stumped that abstracting over parallel and
> sequential collections with the generic GenSeq etc types is completely
> broken. See this example:
>
> val items = (0 to 10000)
> val parItems: collection.GenSeq[Int] = if (true) items.par else items.seq
> parItems.map {
>  _ => Thread.currentThread.getName
>
> }
>
> ParVector(Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Thread-107, Thread-107, Thread-107, Thread-107,
> Thread-107, Threa...
>
> In summary, an operation is never executed in parallel if the static
> type of the collection is not a parallel one which is defeating the
> purpose of the generic collections construction completely. This is,
> because dynamic dispatch - as I would have expected it - is
> circumvented by deciding if something should be run in parallel by the
> instance of the CanBuildFrom which is chosen statically instead of at
> runtime.
>
> I find this a bit upsetting since we had quite a discussion months ago
> about the design of the parallel collections and it seems no one
> (including me) did actually test that the resulting implementation did
> what was promised.
>
> Another problem here is that you can't write
>
> val parItems = if (true) items.par else items.seq
>
> without the type annotation, because type inference fails badly here
> (though that seems to be fixed in trunk already).
>
> --Johannes
>
> -----------------------------------------------JohannesRudolphhttp://virtual-void.net

Futures React within Actor

Hi folks,

can anyone please guide me how exactly react works in respect to
futures and actors?

Lets assume following code

class ActorForwardingToFuture extends DaemonActor {

def act() {
	loop {
		react {
			case Foward(toActor,thisMessage) =>{
				println("yes we want to forward message")
				(toActor !! thisMessage).inputChannel.reactWithin(1000) {
					case reply => println("yes, we have got reply on future")
					case TIMEOUT => prinln("no chance, timeout")
				}
				println("This will not get executed")
			}
		}
	}
}
}

now I see that println("This will not get executed") will never get
executed (which originally surprised me, as I have beleived that the
react only within given actor would cause the after-react code to be
ignored, not the one after future).

This behavior drived me to following conclusions, and I just would
like to reconfirm if them are correct:

1. The reply to future IS SYNCHRONIZED on parent actor, and not on the
future only
2. Obviously actor and future are sharing same threadpool (fork join)
3. In between reply to future actor may proceed freely the actual
messages designated to them and future reply would not block actor
from doing so

Are these assumptions correct? I didnt found anything specific on
actor's futures in the docs, books etc, and this part of story sees to
be quite gray, so I would appreciate any light on how the intended
behavior of Actor//Future/react is

Thanks a lot.

P.

Scripts not running inherited main method

Hi,

Given the following class:

class Foo {
   def main(args: Array[String]) = {
     println("Foo")
   }
}

And the following script:

object Bar extends Foo

...running "scala Bar.scala" produces no output. Is this a bug or a  
feature?

If I try adding a main method to Bar, then Scala tells me I need an  
"override" directive, which makes sense. But shouldn't the script executer  
also recognize the inherited main method?

Regards,
   Rickard Nilsson