mpilquist/simulacrum

First class syntax support for type classes in Scala

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…

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?

Georgi Krastev

@joroKr21

It should be possible (#: is one example)

Fabrizio Colonna

@ColOfAbRiX

Hi! I wanted to learn adn add Simulacrum to one of my project but I keep getting typeclass annotation should have been removed by simulacrum but was not. I can't understand why, I'm using scala 2.13, sbt 1.3.8, simulacrum 1.0.0 and I'm copy-pasting the example in the github readme

forgot to say I have "-Ymacro-annotations" in my compiler options

Fabrizio Colonna

@ColOfAbRiX

Solved. If anyone is interested the sbt plugin Splain was messing up with Simulacrum

Pablo Cavallo

@pacdaemon

Hi I have an error but I can't figure out what is happening

@typeclass trait Monad[F[_]] { self =>
  def flatten[A](ffa: F[F[A]]): F[A] =
    ???

  def notNested[A](fa: F[A]): F[A] =
    ???
}

The flatten with the nested context throws a compilation error

Error:(19, 2) exception during macro expansion: 
scala.ScalaReflectionException: object scala.reflect.macros.blackbox.Context in compiler mirror not found.
    at scala.reflect.internal.Mirrors$RootsBase.staticClass(Mirrors.scala:145)
    at scala.reflect.internal.Mirrors$RootsBase.staticClass(Mirrors.scala:29)
    at simulacrum.TypeClassMacros$$typecreator1$2.apply(typeclass.scala:218)
    at scala.reflect.api.TypeTags$WeakTypeTagImpl.tpe$lzycompute(TypeTags.scala:237)

The method notNested not. Btw I'm using simulacrum 1.0.0, Scala 2.13.3

I got the same error switching to the mpilquist 0.19 version. @mquilquist, as you can guess I'm following your series on youtube about Functional Structures on Scala, but with newer versions of the libraries.

Pablo Cavallo

@pacdaemon

Update creating an aliast to the nested context allows compilation type NF[A] = F[F[A]]

Michael Pilquist

@mpilquist

Hm, that definitely seems like a bug, though it’s been a while since I’ve looked at simulacrum source. With Dotty’s support for extension methods (and lack of support for macro annotations), Simulacrum has been effectively EOLed. Hope the YouTube series is helpful :)

Where communities thrive

People

Repo info

Activity