mpilquist/simulacrum

First class syntax support for type classes in Scala

Peter Mortier

@kwark

......... NBN H. .jg nuuuuu h....u..iiiiiiiiiiiii y..

Jasper Moeys

@Jasper-M

Cat on the keyboard?

Lef Ioannidis

@elefthei

Any ideas why "import simulacrum" is failing with "not found: object simulacrum" in IntelliJ compilation? InltelliJ syntax indicates it finds the library and does auto-complete

simulacrum-0.10 unfortunately so this is before "macro-paradise" was a dependency, I think it needs no compiler plugin support?

Jasper Moeys

@Jasper-M

@elefthei just to be clear, is import simulacrum the complete line of code? Cause an import statement that doesn't include at least one . is not legal syntax, so that might be the problem then.

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.

Siddhant Sanyam

@siddhant3s

That's how IntelliJ is able to let you use the @op methods without putting a red marking on it: https://github.com/JetBrains/intellij-scala/blob/f55df32c25093dce4621f20488b825a3fa9c93d6/scala/scala-impl/src/org/jetbrains/plugins/scala/lang/psi/impl/toplevel/typedef/simulacrum/SimulacrumInjector.scala

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…

Where communities thrive

People

Repo info

Activity