Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:37
    retronym synchronize #9291
  • 05:29
    retronym synchronize #9291
  • 05:01
    som-snytt commented #4940
  • 04:58
    som-snytt commented #4940
  • 04:28
    SethTisue demilestoned #9290
  • 04:28
    SethTisue milestoned #9291
  • 04:28
    SethTisue demilestoned #9291
  • 04:26
    SethTisue commented #4940
  • 04:25
    SethTisue commented #4940
  • 04:24
    retronym edited #9291
  • 04:23
    retronym edited #9291
  • 04:23
    retronym review_requested #9291
  • 04:23
    scala-jenkins milestoned #9291
  • 04:23
    retronym opened #9291
  • 04:20
    nigredo-tori commented #4940
  • 04:17
    SethTisue commented #4940
  • 04:17
    SethTisue commented #4940
  • 04:17
    SethTisue commented #4940
  • 03:42
    retronym closed #9290
  • 03:06
    SethTisue edited #12165
Ivan Trepakov
@liontiger23
But all FP classics like filter, map, fold, reduce are just verbs...
These for some reason don't feel like danger to me
Luis Miguel Mejía Suárez
@BalmungSan
@keynmol I mean that there is no sort that mutates the collection is sortInPlace so why does the immutable one is not called sort?
Ivan Trepakov
@liontiger23
Maybe the end goal is to introduce sort and deprecate sorted?
Luis Miguel Mejía Suárez
@BalmungSan
No idea, and if so that won't happen until 3.1 so a long time for that.
And that would just break a lot of code without no real gain.
Seth Tisue
@SethTisue
@liontiger23 I thought I might find a design discussion about the naming convetion at https://github.com/scala/collection-strawman but failed (perhaps there is one and I just didn't find it). the likeliest person to remember is @julienrf . I also took a quick look at the collections guides and didn't see anything (https://docs.scala-lang.org/overviews/index.html). I'd suggesting starting a thread about it on https://contributors.scala-lang.org and maybe some doc improvements will come out of it
oscar-broman
@oscar-broman
Oh yeah @liontiger23 that's true...
Ivan Trepakov
@liontiger23
@SethTisue Alright, I'll do that. Thanks!
Dmitry Sabanin
@dsabanin
what's the best test/spec framework to use for tagless-final/cats/cats-effect/spark scala 2.12 project?
ideally with good IntelliJ support
is ScalaTest a good choice?
Fabio Labella
@SystemFw
they can all make do one way or another, as I said above weaver or munit+munit-cats-effect would be my preferences
in your case, given that you mention a mix of pure FP with other flavours of scala, and intellij support, I'm inclined to say munit plus munit-cats-effect
Rob Norris
@tpolecat
Those work well for me.
sinanspd
@sinanspd
@closca_emma_twitter you can use forall to assert conditions on all the elements. You could either nest two of these, or flatten the outer List. As for the column wise check, since you don't know the number of lists before hand, your best bet would be use the built in transpose function and repeat the above I think
Gabor Juhasz
@gjuhasz86
@closca_emma_twitter btw are you editing your comment and removing the code on purpose?
Hanns Holger Rutz
@Sciss

Just shot myself in the foot by writing

            for {
              _ <- afIn .read (buf, 0, len)  // def read : Future[Unit]
              _ <- afOut.write(buf, 0, len)  // def write: Future[Unit]
            } yield loop(off + len)          // def loop : Future[Unit]

instead of

            for {
              _ <- afIn .read (buf, 0, len)
              _ <- afOut.write(buf, 0, len)
              _ <- loop(off + len)
            } yield ()

I guess it's a pitfall (Future[Unit]). Any better approaches, to avoid writing yield ()? Seems like a useless additional map to me

Princess | April
@NthPortal
we need better warnings for discarding Unit I think
Hanns Holger Rutz
@Sciss
I guess there is a compiler flag I could turn on to disallow implicit def (x: Any): Unit = () ?
Luis Miguel Mejía Suárez
@BalmungSan
Wait
Princess | April
@NthPortal
uh... not sure
Luis Miguel Mejía Suárez
@BalmungSan
There is a compiler flag that will warn on your first snippet.
Princess | April
@NthPortal
@som-snytt would know
Luis Miguel Mejía Suárez
@BalmungSan
But I do not know what you mean on your last message.
@Sciss

Seems like a useless additional map to me

If you use bm4 that last map is removed but the syntax is the same.

IIRC there was a proposal to allow something like } yield <- Fb on dotty but I do not remember what happened to it, pretty sure it wasn't included.
Seth Tisue
@SethTisue
are you thinking of -Wvalue-discard?
Hanns Holger Rutz
@Sciss
@SethTisue exactly, thanks
Princess | April
@NthPortal
I'm not sure if that will actually catch it, but you can try
Hanns Holger Rutz
@Sciss
it did work in this case (emitted a warning)
Luis Miguel Mejía Suárez
@BalmungSan
Yep, that flag is a must on pure FP.
nigredo-tori
@nigredo-tori

I've just found that when building a PartialFunction, we can transform the argument before match:

scala> val f: PartialFunction[String, Int] = _.toInt match {
  case 0 => 0
}
f: PartialFunction[String,Int] = <function1>

scala> f.isDefinedAt("0")
res7: Boolean = true

scala> f.isDefinedAt("1")
res8: Boolean = false

scala> f.isDefinedAt("foo")
java.lang.NumberFormatException: For input string: "foo"
  at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  at java.base/java.lang.Integer.parseInt(Integer.java:652)
  at java.base/java.lang.Integer.parseInt(Integer.java:770)
  at scala.collection.immutable.StringLike.toInt(StringLike.scala:304)
  at scala.collection.immutable.StringLike.toInt$(StringLike.scala:304)
  at scala.collection.immutable.StringOps.toInt(StringOps.scala:33)
  at $anonfun$1.isDefinedAt(<console>:11)
  at $anonfun$1.isDefinedAt(<console>:11)
  ... 36 elided

Is that the expected behavior? Can I rely on it?
This is with Scala 2.12.

Seth Tisue
@SethTisue
@nigredo-tori PartialFunction is just a trait with isDefinedAt and apply methods, you can implement them however you want
although, hmm. why does this work?
nigredo-tori
@nigredo-tori

@SethTisue, I know that I can do whatever I want with the trait. The question is whether this syntax quirk and the behavior of the resulting PartialFunctions are a part of the specification, or is that undefined behavior.

hmm. why does this work?

Yep, that was my reaction as well. :smile:

Seth Tisue
@SethTisue
yeah it just took me a second :-)
it works in Dotty as well
-Vprint:_ shows that after typer it's:
      private[this] val f: PartialFunction[String,Int] = ({
        @SerialVersionUID(value = 0) final <synthetic> class $anonfun extends scala.runtime.AbstractPartialFunction[String,Int] with java.io.Serializable {
          def <init>(): <$anon: String => Int> = {
            $anonfun.super.<init>();
            ()
          };
          final override def applyOrElse[A1 <: String, B1 >: Int](x$1: A1, default: A1 => B1): B1 = (scala.Predef.augmentString(x$1).toInt: Int @unchecked) match {
            case 0 => 0
            case (defaultCase$ @ _) => default.apply(x$1)
          };
          final def isDefinedAt(x$1: String): Boolean = (scala.Predef.augmentString(x$1).toInt: Int @unchecked) match {
            case 0 => true
            case (defaultCase$ @ _) => false
          }
        };
        new $anonfun()
      }: PartialFunction[String,Int]);
      <stable> <accessor> def f: PartialFunction[String,Int] = $iw.this.f
Seth Tisue
@SethTisue
it crashes the 2.7 compiler, but then starts working in 2.8
omg there is special spec language for this
SLS 6.23.1
When a PartialFunction is required, an additional member isDefinedAt is synthesized, which simply returns true. However, if the function literal has the shape x => x match { …

}, then isDefinedAt is derived from the pattern match in the following way: each case from the match expression evaluates to true, and if there is no default case, a default case is added that evaluates to false.
but note that the spec language says x => x, not x => (some arbitrary expression) match ...
poking around scala/bug...
Seth Tisue
@SethTisue
scala/bug#4940 is squarely in this area, but isn't exactly the same
I don't see any other relevant tickets (which doesn't prove they don't exist)
@nigredo-tori can you record this in a comment on 4940? great find!!
Seth Tisue
@SethTisue
my reason for suggesting commenting on 4940 rather than opening a separate bug is that 4940 is already about the SLS 6.23.1 langugage being interpreted too loosely. and you've found that it's even looser than we previously realized
nigredo-tori
@nigredo-tori

can you record this in a comment on 4940?

Done.