Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Anton Sviridov
@velvetbaldmime:matrix.org
[m]
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)
Andrew Valencik
@valencik
Hmmm, ok. So with Eq.instance I would need to define my own (A, A) => Boolean function for equality?
Anton Sviridov
@velvetbaldmime:matrix.org
[m]

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)
something like this
Andrew Valencik
@valencik
Ahhh... this is still a bit unfortunate as Thing here is a big simplification of what I really have, which involves two type params and a handful of other arguments.... any many of them
Thank you though, you've really cleared this up for me :)
Anton Sviridov
@velvetbaldmime:matrix.org
[m]
There's kittens for automatically deriving instances: https://github.com/typelevel/kittens
zeroexcuses
@zeroexcuses
with cats-effects, do we get "pure as Haskell" in the sense that a function can only do effects explicitly stated in it's type signature, or do we get "functional as ocaml/rust" in that functions can do all types of mutations not stated in the signature ?
sinanspd
@sinanspd
there is nothing preventing you from mutating a global variable from inside of an IO
Fabio Labella
@SystemFw
@zeroexcuses the point of IO is not really to statically segregate effects by type, even though you also get that
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
eugene yokota
@eed3si9n
added herding cats day 18, a bit about IO - https://eed3si9n.com/herding-cats/day18.html
zeroexcuses
@zeroexcuses
Does Scala have a concise definition of the type system on the level of "types and programming languages", or does it go the other side of "the implementation is the spec" ?
Martijn
@martijnhoekstra:matrix.org
[m]
The theorectical foundations of scala 3 are called DOT, which was developed from observations of scala 2.
is that what you were asking?
zeroexcuses
@zeroexcuses
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"
Martijn
@martijnhoekstra:matrix.org
[m]
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
Rohan Sircar
@rohan-sircar

there is nothing preventing you from mutating a global variable from inside of an IO

it's still said to be "pure" right? I'm assuming Haskell does not allow this?

zeroexcuses
@zeroexcuses
Haskell has unsafeIO, though I'm not sure if that is fair game.
Fabio Labella
@SystemFw
that's not fair game imho
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
zeroexcuses
@zeroexcuses
True, maybe I should specify it as Haskell98 w/o extensions -- that, I think, is still straight forward.
Fabio Labella
@SystemFw
yeah, I agree with that, but that language essentially doesn't exist in practice, ~every single library on earth uses various extensions
zeroexcuses
@zeroexcuses

Wait, so is Scala3 fully dependently typed? i.e. can we have type signatures f the form

concat(a: Vec of length M, b: Vec of length N) -> Vec of length (M + N)

?

Fabio Labella
@SystemFw
scala 3 is not fully dependently typed
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
zeroexcuses
@zeroexcuses
in terms of lambda cube, can we have types that depend on values ? i.e. n: Int, v: Vec of length n
Martijn
@martijnhoekstra:matrix.org
[m]
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
Fabio Labella
@SystemFw
@zeroexcuses not directly, so Scala is not fully dependent
an easier definition is to consider where the "type arrow" is the same as the "value arrow"
in Scala it's not
the type arrow in Scala is [A, B], the value arrow is =>
in Idris they are the same
Rich
@Rich2
What do people think of how Idris 2 is shaping up?
zeroexcuses
@zeroexcuses
I really hope Idris succeeds, but imho, dependently typed languages suffer the problem that you need really really really good IDE integration to fill in types.
Rob Norris
@tpolecat
This message was deleted
bblfish
@bblfish:matrix.org
[m]
I was just looking at cats.Show. The documentation does not provide very good reason to use it. I wonder if I have found one.
I have written co-operating-systems/Reactive-SoLiD#13 that produces datastructues like ListMap, Long a Dictionary and a few others, and I would like to have specify a way to serialise the results for HTTP Signature. This needs to be done in a precise way. Is this the right place to use Show?
Ethan
@esuntag:matrix.org
[m]
bblfish: You can think of Show largely as a better version of toString, ensuring that there is a sensible String representation of the object. I'd be hesitant to use it outside of debugging and logging contexts. If you need to serialize, then you probably want some sort of Encoder typeclass
bblfish
@bblfish:matrix.org
[m]
Ah good to know. Is theree a good one I should use?