Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 09:18
    GusevTimofey starred mpilquist/simulacrum
  • Jan 29 2019 12:01
    mriceron starred mpilquist/simulacrum
  • Jan 25 2019 15:35
    shuttj starred mpilquist/simulacrum
  • Jan 19 2019 20:51
    driuzz commented #124
  • Jan 19 2019 17:54

    mpilquist on master

    Updated README for 0.15 release (compare)

  • Jan 19 2019 16:03

    mpilquist on v0.15.0

    (compare)

  • Jan 19 2019 16:03

    mpilquist on master

    Setting version to 0.15.0 Setting version to 0.15.1-SNAPS… (compare)

  • Jan 19 2019 15:16

    mpilquist on master

    Update scalatest to 3.0.6-SNAP6 Merge pull request #125 from sc… (compare)

  • Jan 19 2019 15:16
    mpilquist closed #125
  • Jan 19 2019 15:15

    mpilquist on master

    Update sbt-release to 1.0.11 Merge pull request #123 from sc… (compare)

  • Jan 19 2019 15:15
    mpilquist closed #123
  • Jan 19 2019 15:15

    mpilquist on master

    Add support for DocDef Add support for DocDef - test Disabled ScalaDoc generation on… and 2 more (compare)

  • Jan 19 2019 15:15
    mpilquist closed #124
  • Jan 19 2019 15:10
    mpilquist commented #124
  • Jan 19 2019 15:10
    mpilquist synchronize #124
  • Jan 19 2019 15:09
    mpilquist synchronize #124
  • Jan 19 2019 04:34
    wangpengwen starred mpilquist/simulacrum
  • Jan 18 2019 13:57
    scala-steward synchronize #125
  • Jan 18 2019 13:57
    scala-steward synchronize #123
  • Jan 18 2019 12:44

    mpilquist on master

    Future proof subtype evidence … Merge pull request #126 from jo… (compare)

Lef Ioannidis
@elefthei
@Jasper-M appologies, it is import simulacrum._
Dominic Egger
@GrafBlutwurst

Good Morning. I have a bit of a build issue suddenly. I get typeclass annotation should have been removed by simulacrum but was not both on:

scala 2.12.8 with macro paradise
scala 2.13.0 with "-Ymacro-annotations"

does anyone know something about that? but It also might be something that broke elsewhere. I tried updating sbt from 1.2.8 to 1.3.0-RC1 which caused sbt run to fail with missing class errors (even though sbt console and calling main worked just fine) downgrading back to 1.2.8 suddenly caused these errors to appear. it worked fine before
Mike Slinn
@mslinn
I've put together a small sbt project to experiment with Simulacrum. So far all good except for the entry point that tries to work with an ADT. Suggestions?
Mike Slinn
@mslinn
Anyone out there would would like to take a quick look at the ADT I mentioned?
Yilin Wei
@yilinwei
@mslinn I don't remember if it works with bounds on A. Did you try compiling without?
A <: Direction I mean.
Mike Slinn
@mslinn
@yilinwei The same error message appears whether or not bounds on A are provided: Does not compile: value truthy is not a member of object North, South, East or West:
import simulacrum._

// True north is the only truthy direction
sealed trait Direction
object North extends Direction
object South extends Direction
object East  extends Direction
object West  extends Direction

trait TruthyImplicits3 {
  @typeclass trait Truthy[A] { self =>
    /** @return true if `direction` is truthy. */
    @op("truthy") def truthy(direction: A): Boolean
  }

  implicit val directionCanTruthy: Truthy[Direction] = {
    case North => true
    case _ => false
  }
}

object CanTruthy3 extends App with TruthyImplicits3 {
  import Truthy.ops._

  println(s"North.truthy = ${ North.truthy }")
  println(s"South.truthy = ${ South.truthy }")
  println(s"East.truthy  = ${ East.truthy }")
  println(s"West.truthy  = ${ West.truthy }")
}
Yilin Wei
@yilinwei
@mslinn Does it compile without the truthy invocations i.e. are the ops generated? Also I don't think you need @op on the typeclass either.
Mike Slinn
@mslinn
@yilinwei If the 4 printlns at the bottom are commented then it compiles and runs. The import remains so it seems the ops are generated.
Yilin Wei
@yilinwei
And without the op?
Mike Slinn
@mslinn
Without @op("truthy") I see no change.
The printlns cannot be uncommented with or without the @op
Yilin Wei
@yilinwei
@mslinn OK, I checked out the project. It's scala's inference rules on the ops which is causing issues.
``````
Mike Slinn
@mslinn
... moving closer to hear you better ...
Yilin Wei
@yilinwei
object CanTruthy3 extends App with TruthyImplicits3 {
  import Truthy.ops._

  def north: Direction = North
  def south: Direction = South

  println(s"North.truthy = ${ north.truthy }")
  println(s"South.truthy = ${ south.truthy }")
}
Mike Slinn
@mslinn
Alright, those defs do the job, but I do not understand why or what that means.
Yilin Wei
@yilinwei
OK, so there's an implicit conversion going from Direction to a class which is generated by simulacrum (that's what the ops pattern is for). So that you can call foo.bar even though bar is not a member of foo.
North on the other hand has a type of North rather than Direction. It's a subtype of Direction but not of type Direction.
Mike Slinn
@mslinn
I think you are saying that each subtype in an ADT will need an extra level of indirection
I can happily work with that, thanks.
Yilin Wei
@yilinwei
Yes - in practice you aren't going to hit into the issue (it's been ages since I did this since functions have variance) so def doTruthy[A : Truthy](a: A) = a.truthy will always work.
(Or a function taking in Direction)
Mike Slinn
@mslinn
What would such a function look like?
Yilin Wei
@yilinwei
def doTruthy(d: Direction) = d.truthy
With the ops imported and the implicit for Directioin in scope.
Mike Slinn
@mslinn
The first doTruthy does not compile if placed in object CanTruthy3. The second must be explicitly called, and it leads to non-obvious coding:
  def doTruthy(d: Direction): Boolean = d.truthy
  println(s"North.truthy = ${ doTruthy(North) }")
Yilin Wei
@yilinwei
I've just deleted the repo, but it should be fine (caveat the right implicits are in scope) - what I'm saying is that it's unlikely you'll ever call the subtype directly when you're using a typeclass in your "production" code.
Mike Slinn
@mslinn
According to my present understanding, I'll need to work with the 4 directions explicitly in my code. For example, I'll want to call North.truthy (or north.truthy)... or do I misunderstand what you mean?
@yilinwei I must deal with other things for a few hours. Most interested in this thread, will return ASAP. Many thanks for your time and help so far :)
Yilin Wei
@yilinwei
I meant I'd probably write something like this def printTruthy[A : Truthy : Show](a: A): Unit = println(s"${a.show}.truthy = ${a.truthy}"). Note that you don't code on a concrete type, your A here only has two operations Show and Truthy. The Show is from cats and is a typeclass with the method def show(a: A): String.
Mike Slinn
@mslinn
@yilinwei I did some work on CanTruthy3. Questions and comments are embedded. Looking forward to responses from anyone so inclined.
Siddhant Sanyam
@siddhant3s
From what I can understand, Simulacrum uses IntelliJ's SyntheticMethodInjector to inject the method generated by @ops. If the definition of the Typeclass is itself being generated by a macro, will IntelliJ be able to see those @ops?
Yilin Wei
@yilinwei
@siddhant3s Simulacrum has nothing to do with IntelliJ?
Macros are nested expansions and I'm guessing IntelliJ might be able to see it in target, but you won't be able to see it in the file I guess?
Siddhant Sanyam
@siddhant3s
I mean, IntelliJ's official Scala plugin has support for Simulacrum's injected methods using @ops
Yilin Wei
@yilinwei
Oh, no idea.
Yilin Wei
@yilinwei
In which case, I suspect it would be unlikely that it would find the op inside a macro expansion since they wouldn't need special support for it otherwise.
Siddhant Sanyam
@siddhant3s
Hmm... I think you're right.
But that would depend on if the macro's are really executed within IJ or not. WhiteBox macros allow you to return a more specific type than what is there on the macro definition. And if so they are really being executed by IJ, then I can imagine the plugin be able to read the annotation and dynamically inject methods.
Seems like there is no way in Scala/Macro to really create a dynamically named method on fly and have it work with IJ.
Marcin Kossakowski
@markosski
Hi guys, I'm trying out simulacrum and running into an issue with running first example from readme - typeclass annotation should have been removed by simulacrum but was not. I'm on Scala 2.12.8. I ensured simulacrum dependency and compiler plugin was added as per readme instructions.
Maxim Davydov
@Twizty
Hi people, I'm working on the issue at cats (typelevel/cats#3141), and have found strange behavior of simulacrum. I've implemented a method def foldA[G[_], A](fga: F[G[A]])(implicit G: Applicative[G], A: Monoid[A]): G[A] for Foldable and it's compiled to def foldA[G[_], A](implicit ev$macro$49: <:<[D, G[A]], G: Applicative[G], A: Monoid[D]) = typeClassInstance.foldA(self.asInstanceOf[F[G[A]]])(G, A); which fails. Is it a bug or am I doing something wrong?
Travis Brown
@travisbrown
I've been experimenting with a reworking of Simulacrum that's built on scala.meta + scalafmt and based on codegen instead of macro annotations…
The idea is that in Cats 3 the type class machinery would go in managed source, but I'm pretty close to having a Cats 2 proof-of-concept that just expands the checked-in source (while still passing all tests + bincompat checks).
I think you've mentioned ideas like this, @mpilquist—do you happen to know if anyone else has worked on it?
Yilin Wei
@yilinwei
@travisbrown Apologies for the late reply. I swear that a long time ago Eugene or Oleg had a branch with it.
Jasper Moeys
@Jasper-M
I thought I saw a scalameta implementation of simulacrum somewhere once, but it was probably not complete and now also outdated. Can't find it anymore though.
Brian P. Holt
@bpholt
If a typeclass has methods with by-name parameters, afaict ops methods aren't generated for those methods. Is that because they aren't possible, no one has implemented it, or it's a bad idea?