Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html
i'll go take this into that channel
There's an API and various tools to generate an archive from it. There have been a couple attempts at public archives in the past that raised ire on GDPR grounds. I am neither a lawyer nor a European. If you do it, I didn't endorse it, and please don't share it. But people can and do.
I've had enough success with Google and a site filter where the built-in search fails.
Is cats/scalaz/functiona llibraries useful for "inventing a database" as in https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf . So in particular, I am interested in a style of programming where all data is stored in relational tables (say sqlite3 or h2), but instead of updating the data via SQL, we update the data via Scala.
When going from scala 2.13.4 to 2.13.5 I get unused implicit warning/errors when I try and create an
Is this a false positive, or am I doing something wrong here?
Eq instance for a parameterized type: https://scastie.scala-lang.org/UknDiddWSLul5NTLoMr7zAIs this a false positive, or am I doing something wrong here?
import cats.Eq
final case class Thing[A](a: A)
object Thing {
implicit def eqThing[I: Eq]: Eq[Thing[I]] = Eq.fromUniversalEquals
}parameter value evidence$1 in method eqThing is never used
Yeah, you're requesting that there's a
Eq[I], but you don't use that knowledge - you delegate to a method that constructs an Eq instance without any knowledge of the underlying type: https://github.com/typelevel/cats/blob/main/kernel/src/main/scala/cats/kernel/Eq.scala#L106
Instead, you can express it using
Eq.instance and in it you can use the Eq[I] instance
this thing is a new warning in 2.13.5, which marks unused implicits even if they were synthesized by the compiler (as is the case with
I: Eq syntax)
in this case you just want to delegate - what does it mean for two Thing[I] to be equal? for their thing.a to be equal.
And you have the Eq[I] instance to compare just the as
implicit def eqThing[I: Eq]: Eq[Thing[I]]
This says "If I know how to check equality of things of type I, I can also check equality of things of type Thing[I]"
You just need to use Eq.instance to wire things together
ah, there's actually
Eq.by which is even simpler
implicit def eqThing[I: Eq]: Eq[Thing[I]] = Eq.by(_.a)
Thank you though, you've really cleared this up for me :)
it's to be able to treat effectful programs as values, which enable compositional apis
in Scala, being as "pure as Haskell" is a matter of discipline, in that there is nothing preventing you from "cheating"
but this isn't as big of a deal as it sounds: cats-effect codebases are as pure as Haskell, in practice
and in a few ways they are better than Haskell since cats-effect
IO is more modern than Haskell's
The theorectical foundations of scala 3 are called DOT, which was developed from observations of scala 2.
Papers like https://link.springer.com/chapter/10.1007/978-3-319-30936-1_14 formalize it
is that what you were asking?
In my very limited understanding of type systems, HM inference is fairly straight forward; SML is fairly straight forward, OCaml seems to have added lots of object oriented stuff, Rust is relatively straight forward, Haskell , without extensions is relatively straight forward; as for Scala 2.13, I can't figure out where to place it -- whether there is a "simple core" or whether it has lots of components. This is what I had in mind for "paper" vs "implementation" -- is there a clear theoretical descriptin of the type system, or is it "the implmenetation is the spec"
Type checking is based on the DOT calculus, which is its own thing, made for scala 3. It has dependent object types and subtyping, which HM doesn't have.
Inference is essentially unspec'ed. The implementation is the spec there. But inference always typechecks
btw I wouldn't call Haskell straightforward at this point, the type system is very complicated overall
same with SML and OCaml, the core language is straightforward, but the theory behind modules is very very complex
although the type signature you have used as an example doesn't required full dependent types
Scala uses the term "dependent typing" for a feature which, although it shows a certain degree of "dependence", isn't full dependent types a la Idris or Agda
scala 3 has the same path dependent types as scala 2: if you have a
trait Foo { type X }, and a value val foo: Foo (but not var foo or def foo), then you can talk about the type foo.X