Dave | 2 Jul 13:14 2011
Picon

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

Donna Malayeri | 4 Jul 02:22 2011
Picon

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

Marc CARRÉ | 3 Jul 22:06 2011
Picon

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

Clarence Gardner | 4 Jul 07:25 2011
Picon

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, <scala-language+noreply <at> googlegroups.com> wrote:

Group: http://groups.google.com/group/scala-language/topics

    Dave <dave.mahabiersing <at> hotmail.com> 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...

Andy Hicks | 4 Jul 10:57 2011
Picon

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) - Collective Summer Camp UK 2011 (£)

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






Ruediger Keller | 4 Jul 11:09 2011
Picon

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
>

Dave | 4 Jul 13:13 2011
Picon

Re: Why <: and not <=: ?

Thanks, Donna.

Johannes Rudolph | 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 {
 _ => 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

Aleksandar Prokopec | 4 Jul 17:25 2011
Picon

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

Pavel Chlupáček | 4 Jul 19:31 2011
Picon

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