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 09:18
    GusevTimofey starred mpilquist/simulacrum
  • Jan 29 12:01
    mriceron starred mpilquist/simulacrum
  • Jan 25 15:35
    shuttj starred mpilquist/simulacrum
  • Jan 19 20:51
    driuzz commented #124
  • Jan 19 17:54

    mpilquist on master

    Updated README for 0.15 release (compare)

  • Jan 19 16:03

    mpilquist on v0.15.0

    (compare)

  • Jan 19 16:03

    mpilquist on master

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

  • Jan 19 15:16

    mpilquist on master

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

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

    mpilquist on master

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

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

    mpilquist on master

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

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

    mpilquist on master

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

Michael Pilquist
@mpilquist
Yeah that’s still true. In practice, escape analysis seems to handle the performance concerns in most cases
Jakub Kozłowski
@kubukoz
Hi, is it safe to scope simulacrum as a compile-only dependency?
Michael Pilquist
@mpilquist
Yeah, take a look at cats-build
There’s a trick to keep Intellij happy
Jakub Kozłowski
@kubukoz
of course, intellij...
Jasper Moeys
@Jasper-M
My trick to keep myself happy is not using Intellij
Wojciech Daniło
@wdanilo
Hi guys! I'm trying to convert the following code to simulacrum. Using "Haskell language", what I need here is just a superclass constraints when solving typeclass instances. Can we express something like that in Simulacrum?
  import shapeless.Lazy

  sealed trait AST[T]
  case class Var[T](s: String) extends AST[T]
  case class App[T](a: T, i: Int, b: T) extends AST[T]

  case class Fix[F[_]](unfix: F[Fix[F]])

  trait HasSpan[T] {
    def span(t: T): Int
  }
  object HasSpan {
    implicit def astSpan[T](implicit ev: Lazy[HasSpan[T]]): HasSpan[AST[T]] = new HasSpan[AST[T]] {
      def span(t: AST[T]) = t match {
        case Var(s) => s.length
        case App(a, i, b) => ev.value.span(a) + i + ev.value.span(b)
      }
    }

    implicit def inductive[F[_]](implicit ev: Lazy[HasSpan[F[Fix[F]]]]): HasSpan[Fix[F]] = new HasSpan[Fix[F]] {
      def span(f: Fix[F]) = ev.value.span(f.unfix)
    }
  }
  def test: Fix[AST] = Fix(Var("x"))

  def a = implicitly[HasSpan[Fix[AST]]].span(test)
Of course, the typeclass definition is straightforward, the problem is how to implement the instances, especially the instance for (using Haskell syntax) HasSpan F => HasSpan (Fix F)
@typeclass trait HasSpan[A] {
  def span(a: A): Int
}
Jakub Kozłowski
@kubukoz
I think that's what we do in instances indeed and the way to do it is just like you showed
simulacrum won't help much
Wojciech Daniło
@wdanilo
@kubukoz thanks Jakub! From a Haskellers perspective thats terrible, but ok, lets live with that :D
Jakub Kozłowski
@kubukoz
well you don't need Lazy on 2.13...
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.