Filter on future doesn't make sense

[Avi Levi]

I was trying to figure out what should I accept when filtering over a future .

the current implementation yields either a T or an exception which kind of breaks referential transparency (doesn't it ?) .

on the other hand what can I expect given this expression 

def foo(i:Int):Future[Int]

the type result of 

foo(1).filter(_ % 2 == 0)

I.M.H.O I would expect it to yield Option[T]  which makes more sense to express that we might get a value that pass the filter or not . is that make sense ?

Cheers

Avi 

[Viktor Klang]

Hi Avi,

Use Fututre[Option[Int]] if you want to deal with Some/None as a result of filter ( f.map(_.filter(p) ) (alt. see monad transformers)

--
Cheers,
√

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Avi Levi]

Thanks Victor,
Of course it can be implemented as you suggested. But still I can argue that the current implementation is not "really filtering" the results as one might expect and less expressive if it might or not return the value than Option is more expressive, don't you agree?

You received this message because you are subscribed to a topic in the Google Groups "scala-language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-language/wpGOB8f7qmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-languag...@googlegroups.com.

[Viktor Klang]

Hi Avi,

I see what you mean.

I'd want to avoid discussing expectation since it is subjective. I will however note that the actualnsemantics of the filter method on Future needs improvement: http://www.scala-lang.org/api/2.11.8/index.html#scala.concurrent.Future@filter(p:T=>Boolean)(implicitexecutor:scala.concurrent.ExecutionContext):scala.concurrent.Future[T]

As for might not return the value, the same goes for all filter-methods:

List returns List, but it might not have any elements at all. Option returns Option but can be Some or None, Future is either Success or Failure.

If success has an optionality aspect in your usage, use Future of Option to express that, that would be my recommendation.

--
Cheers,
√

[Avi Levi]

Hi Victor ,

I totally agree that expectations are subjective .

But like you said a filter on List will return a List if no element comply than we will get Nil which represents an empty container (empty list)

a filter on option will return a option if the element doesn't comply than we will get None which represents an empty container 

following the same logic a filter on future should return something that express empty container , defiantly not an exception, because it is not an exception we do intend to filter those elements.

 

Sincerely,
Avi Levi

m: +972-52-3459959

https://about.me/avi.levi

[Viktor Klang]

But you don't get an exception on the success path. All operations on the success path will be skipped, just as for Option.

--
Cheers,
√

[Avi Levi]

Correct, just on future you get an exception if element does not pass the filter. Wouldn't it be better if we can get something that express an empty future?

[Viktor Klang]

I think you are conflating the notion of optionality here.

option.filter(p).map(f).foreach(println)

behaves exactly like

future.filter(p).map(f).foreach(println)

--
Cheers,
√

[Oliver Ruebenacker]

     Hello,

  Looks like sometimes you do get an exception:

Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).
Type in expressions for evaluation. Or try :help.

scala> import scala.concurrent.Future
import scala.concurrent.Future

scala> import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.ExecutionContext.Implicits.global

scala> Future{1}.onComplete { case _ => println("Complete!") }

scala> Complete!


scala> Future{1}.filter(_ == 0).onComplete { case _ => println("Complete!") }
Complete!

scala> import scala.util.{Success, Failure }
import scala.util.{Success, Failure}

scala> Future{1}.filter(_ == 0).onComplete {
     | case Success(value) => println(value)
     | case Failure(ex) => println(ex)
     | }

java.util.NoSuchElementException: Future.filter predicate is not satisfied
scala>

     Best, Oliver

Oliver Ruebenacker

Senior Software Engineer, Diabetes Portal, Broad Institute

[Viktor Klang]

Hi Oliver,

Which is why I explicitly talked about the success path.
As you saw, onComplete takes both path, much similar to something like toString.

See my previous example for details.

--
Cheers,
√

[Roland Kuhn]

The difference is that Option does not have onComplete: if you restrict yourself to the Option API then Future behaves observably in the same way. If you want to have something like onComplete you should look at Either[NoSuchElementException, T]#fold.

In general there is no .filter on monads because that would require the explicit ability to represent emptiness (which is not part of the contract); the success path for the combinators could be seen as such a representation and it is indeed often used as such, so Future is quite well-behaved in this regard. Another comment I’d like to make on the discussed change is that it is not reasonable to expect that the result of filtering returns a different type than the original one—no other container has this behavior.

Regards,

Roland

[Oliver Ruebenacker]

     Hello Viktor,

  I see. I thought you meant with "success path" that the original Future succeeds, but apparently you mean that also all filters are satisfied.

     Best, Oliver

[Oliver Ruebenacker]

     Hello Roland,

  Option has get, getOrElse and the possibility to match against Some(value), but Future does not have these.

     Best, Oliver

[Roland Kuhn]

Well … technically (and no, this is NOT a good idea, and hence it looks a little odd):

scala> import concurrent._

import concurrent._

scala> import ExecutionContext.Implicits._

import ExecutionContext.Implicits._

scala> import duration._

import duration._

scala> Future(42)

res0: scala.concurrent.Future[Int] = scala.concurrent.impl.Promise$DefaultPromise@25bbf683

scala> Await.ready(res0, 1.second).value.get.toOption

res1: Option[Int] = Some(42)

scala> Await.ready(res0.filter(_ == 1), 1.second).value.get.toOption

res2: Option[Int] = None

Regards,

Roland

[Avi Levi]

Hi Ronald ,

taking the example above 

scala>val x = Future{1}.filter(_ == 0)

scala>x.value

res2: Option[scala.util.Try[Int]] = Some(Failure(java.util.NoSuchElementException: Future.filter predicate is not satisfied))

It seems odd that a legit action such as filter yields a failure with an exception . 

Cheers 

Avi

[Oliver Ruebenacker]

     Hello,

  But that's consistent with options and collections:

scala> Some(1).filter(_ == 0).get
java.util.NoSuchElementException: None.get

scala> Set(1, 2, 3).filter(_ == 0).head
java.util.NoSuchElementException: next on empty iterator

     Best, Oliver

[Viktor Klang]

Hi Avi,

I'm unsure "seems odd" can be discussed successfully, I'm afraid.

As have been demonstrated, filter on Future behaves semantically equivalent to the methods used by for-comprehensions (map, flatMap, filter/withFilter and foreach)

--
Cheers,
√

[Avi Levi]

Viktor, Oliver 

I guess you are correct .

But 

scala> Some(1).filter(_ == 0)

res0: Option[Int] = None

scala> Set(1, 2, 3).filter(_ == 0)

res1: scala.collection.immutable.Set[Int] = Set()

BUT

val x = Future{1}.filter(_ == 0)

Failure(java.util.NoSuchElementException: Future.filter predicate is not satisfied))

[Roland Kuhn]

To my mind the moral to be learnt from this example is that

• pattern matching on internal structure of the container is potentially inconsistent
• monadic combinators (and similar extensions) are more careful in avoiding the exposure of internal details

Whether or not this seems odd lies in the eye of the beholder, but from a theoretical perspective that’s just how it is.

Regards,

Roland

[Viktor Klang]

On Fri, Jul 1, 2016 at 8:12 PM, Avi Levi <123...@gmail.com> wrote:

Viktor, Oliver 

I guess you are correct .

But 

scala> Some(1).filter(_ == 0)

res0: Option[Int] = None

scala> Set(1, 2, 3).filter(_ == 0)

res1: scala.collection.immutable.Set[Int] = Set()

BUT

val x = Future{1}.filter(_ == 0)

Failure(java.util.NoSuchElementException: Future.filter predicate is not satisfied))

So you'd be happy(?) if the toString on a failed future said "Future()"?

(Keep in mind the comment I had about toString earlier in the thread :))

--

Cheers,

√

[Naftoli Gugenheim]

On Fri, Jul 1, 2016, 2:53 AM Avi Levi <123...@gmail.com> wrote:

I was trying to figure out what should I accept when filtering over a future .

the current implementation yields either a T or an exception which kind of breaks referential transparency (doesn't it ?) .

How would it break referential transparency? It's just a value that happens to extend Throwable. (Actually throwing an exception might break RT, but that's not happening.)

Isn't there the same question about Try#filter?

on the other hand what can I expect given this expression 

def foo(i:Int):Future[Int]

the type result of 

foo(1).filter(_ % 2 == 0)

I.M.H.O I would expect it to yield Option[T]  which makes more sense to express that we might get a value that pass the filter or not . is that make sense ?

Cheers

Avi 

--

[Avi Levi]

Yeah, you are right . I take that back

You received this message because you are subscribed to a topic in the Google Groups "scala-language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-language/wpGOB8f7qmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-languag...@googlegroups.com.