2 Jul 13:14 2011

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

```
4 Jul 02:22 2011

### Re: Why <: and not <=: ?

In mathematics, yes, but in type systems, the less-than-equal sign or <: are used interchangeably, with the latter being far more common. It is understood that <: is a reflexive, transitive preorder and would therefore be equivalent to a symbol with an equal sign.

Donna

3 Jul 22:06 2011

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

```
4 Jul 07:25 2011

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

Well, it would be an extra character for no compelling reason, and even when A is in fact B, A < B still holds because B is a subtype of itself.

On Sat, Jul 2, 2011 at 10:43 PM, wrote:
Jul 02 04:14AM -0700 ^

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

4 Jul 10:57 2011

### Upcoming Scala Events in London

Hi

I've generated a list of events for the London Scala User Group and thought that if anybody is not on the group or visiting in the next few months then it may be of interest.
This is all Scala events, not just for the user group (£ indicated paid).  If anybody knows of any others then I would be interested to know.

July
20 - LSUG Talk: Idiomatic Scala with Kevin Wright ( <at> thecoda)
30 (or 6,13 Aug) -

August
10 - LSUG Talk: Practical Scalaz: making your life easier the hard way Chris Marshall ( <at> oxbow_lakes)
16 - Encoding Unboxed Union Types in Scala

September
5  - Miles Sabin's Advanced Scala Development (£)
14  - LSUG Talk ???
14-16 - Scala Tutorials (£)

October
12 - LSUG Talk ???
13-14 - Scala LiftOff London (£)

November
9 - LSUG Talk ???

December

Also: Functional Brighton (with some Scala) is on the 3rd Tuesday of the month.

Big thanks to youDevise for helping with the monthly Dojos and Skillsmatter supplying a room for the talks.

andy

4 Jul 11:09 2011

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

```
4 Jul 13:13 2011

### Re: Why <: and not <=: ?

```Thanks, Donna.

```
4 Jul 13:18 2011

### 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 {
}

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

```
4 Jul 17:25 2011

### 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 {
>
> }
>
>
> 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

```
4 Jul 19:31 2011

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

```

Gmane