Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 09 11:48
  • Dec 09 11:38
  • Dec 09 11:25
    codecov-io commented #803
  • Dec 09 11:25
    joroKr21 synchronize #803
  • Dec 09 11:16
    codecov-io commented #798
  • Dec 09 11:16
    joroKr21 synchronize #798
  • Dec 09 10:48
    Travis milessabin/shapeless (master) passed (2683)
  • Dec 09 10:25

    milessabin on master

    Fix Typeable.describe for symbo… Merge pull request #945 from jo… (compare)

  • Dec 09 10:25
    milessabin closed #945
  • Dec 09 10:25
    milessabin closed #944
  • Dec 09 10:25
    milessabin commented #945
  • Dec 08 19:26
  • Dec 08 19:03
    joroKr21 edited #945
  • Dec 08 19:03
    joroKr21 opened #945
  • Dec 08 15:59
    milessabin closed #942
  • Dec 08 15:54
    ashleymercer commented #942
  • Dec 08 15:48
    milessabin commented #943
  • Dec 08 15:45
    milessabin commented #942
  • Dec 08 15:14
    joroKr21 commented #942
  • Dec 08 15:13
    joroKr21 commented #942
Fabio Labella
@SystemFw
let me redo the one with Poly, it's shorter
David Hoyt
@davidhoyt
@SystemFw this may show my ignorance wrt shapeless -- i am trying to auto-derive type class instances. will that work w/ Poly?
Fabio Labella
@SystemFw
I also did versions with auto-derived type classes
same behaviour
David Hoyt
@davidhoyt
@SystemFw i suppose i'm asking if you can use Poly to derive type classes
Fabio Labella
@SystemFw
actually, when doing the typeclass version I got the other possible bug
@davidhoyt The question is a bit unclear to me
Poly exposes type class instances (Case), which you can use in your typeclass derivation
David Hoyt
@davidhoyt
@SystemFw i am saying that i've never used Poly that way -- i'm somewhere between beginner and intermediate level w/ shapeless
Fabio Labella
@SystemFw
similarly, some typeclasses you also use in derivations (e.g.Mapper, FlatMapper), want a Poly
@davidhoyt right, basically if you have something that works with Poly, you can ask for an implicit Case1 of that Poly
just like you would ask for another typeclass instance
(well, Case1, Case2...what have you)
or, you can write your own custom typeclass (which is what I do most of the time), to replace the poly
David Hoyt
@davidhoyt
@SystemFw i was going down that path primarily because i was unaware of alternatives :)
so I have a "wrapper" type class which I derive and can then turn into the actual type class I care about
Fabio Labella
@SystemFw
is there any reason for not deriving the type class you care about directly?
Fabio Labella
@SystemFw

TIL:

No, the subclass rule and the specificity of the type rule are both run and the score is tallied. If they are in opposite directions, it ends up with ambiguity.

So prioritising implicits to encode typelevel pattern matching precedence does not always work...disappointing

Fabio Labella
@SystemFw
apparently the further trick is make sure the specifity rule tally goes back to 0, so that the subclassing rule kicks back as the decisive factor
Fabio Labella
@SystemFw
@davidhoyt I'm close to solving your problem
David Hoyt
@davidhoyt
@SystemFw please share what you have -- i'd like to learn/collaborate
really appreciate your help
Ryan Williams
@ryan-williams

OT: can i get a Generic for a trait with only abstract fields? e.g. with a structure like this:

trait Foo { def a: A; def b: B; def c: C }
trait Bar extends Foo { def d: D }
trait Baz extends Foo { def e: E }

I want to be able to get Generics for Foo/Bar/Baz.

The context is that I'm trying to have multiple classes/traits share a set of fields while also being able to get a Generic for them, without having to repeat all the fields everywhere. traits can be composed to allow this but but classes/fields/ctor-args can't. cf. https://github.com/alexarchambault/case-app/issues/58#issuecomment-313799457

i'm considering trying to write a macro (annotation?) to do it. i guess some detail on the macro that shapeless uses to get Generics for case classes would be useful too; iirc it hangs off of the existence of a case class's apply method?
Fabio Labella
@SystemFw
@davidhoyt Sorry, had to go away. I have a Poly that flattens arbitrarily nested case classes , preserving the names of the fields in a type akin to a LabelledGeneric#Repr
  case class Foo(a: String, b: Bar)
  case class Bar(c: Int, d: Baz)
  case class Baz(e: Long)

  val v = Foo("A", Bar(1, Baz(2)))

  def a = flatten(v)
  res1: shapeless.::[String with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("a")],String],shapeless.::[Int with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("c")],Int],shapeless.::[Long with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("e")],Long],shapeless.HNil]]] = 
    A :: 1 :: 2 :: HNil
Fabio Labella
@SystemFw
Question: given a Poly f, I can implicitly ask for an instance of that poly for type parameter A by implicit ev: Case[A, f.type].
Provided the types line up, I can compose f with another poly g via object c extends Compose(f, g). How do I implicitly ask for an instance of the composed poly for type parameter A?
Fabio Labella
@SystemFw
nvm, figured it out (Case[c.type, A :: HNil])
@davidhoyt solved it!
David Hoyt
@davidhoyt
@SystemFw great thanks -- i just read all of dave gurnell's book on shapeless :)
@SystemFw please share!
Fabio Labella
@SystemFw
I did it with Polys to learn something different, I think it would have actually been easier (but more verbose), to figure out with just custom typeclasses, but here you go:
  import shapeless._, ops.hlist._, poly._, labelled._

  trait Describe[A] {
    def apply(a: A): String
  }
  object Describe {
    def apply[A](a: A)(implicit ev: Describe[A]) = ev(a).dropRight(2)

    implicit def all[A](
        implicit f: Case.Aux[body.type, A :: HNil, String]): Describe[A] =
      new Describe[A] {
        def apply(a: A) = f.apply(a)
      }
    object body extends Compose(describer, flatten)

    object describer extends LowPrioDescriber {
      implicit def all[H <: HList](
          implicit fm: MapFolder[H, String, describer.type]) =
        at[H](x => fm(x, "", _ + _))
    }
    trait LowPrioDescriber extends Poly1 {
      implicit def base[K <: Symbol, V](implicit key: Witness.Aux[K]) =
        at[FieldType[K, V]](x => s"${key.value.name} = ${x.toString}, ")
    }

    object flatten extends LowPrioFlatten {
      implicit def hlists[H <: HList](
          implicit fm: Lazy[FlatMapper[flatten.type, H]]) =
        at[H](x => fm.value(x))

      implicit def kv[K, V, R](implicit gen: LabelledGeneric.Aux[V, R],
                               rec: Lazy[Case1[flatten.type, R]]) =
        at[FieldType[K, V]](x => rec.value(gen.to(x)))

      implicit def prods[A, R <: HList](
          implicit gen: LabelledGeneric.Aux[A, R],
          rec: Lazy[Case1[flatten.type, R]]) =
        at[A](x => rec.value(gen.to(x)))
    }
    trait LowPrioFlatten extends Poly1 {
      implicit def all[A] = at[A](x => x :: HNil)
    }
  }
example:
  case class Foo(a: String, b: Bar)
  case class Bar(c: Int, d: Baz)
  case class Baz(e: Long)

  val v = Foo("A", Bar(1, Baz(2)))

  def c = Describe(v)
 // res1: String = a = A, c = 1, e = 2
I'll go create a gist
David Hoyt
@davidhoyt
now to parse all of this to see if I can follow it...
Fabio Labella
@SystemFw
since someone else asked this several weeks ago, but I didn't have the time to fully solve it then
David Hoyt
@davidhoyt
this preserves the declaration order, right?
Fabio Labella
@SystemFw
what do you mean?
I tested it with the example you gave me
can't you see it? (gitter is weird sometimes)
one thing that I'm not too sure about
what happens with things like List
David Hoyt
@davidhoyt
e.g.:
case class Foo(a: String, b: Int, c: Bar)
case class Bar(d: Baz, e: Int)
case class Baz(f: Long, g: String)

val v = Foo("A", 1, Bar(Baz(2, "G"), 3))

// a = A b = 1 f = 2 g = G e = 3
I actually don't care about preserving order, but bonus points if it does. I am inclined to think that it preserves it.
Fabio Labella
@SystemFw
res1: String = a = A, b = 1, f = 2, g = G, e = 3
that's the result
however, describer probably needs some modification, it doesn't compile if your case classes have Lists in them
but the basic idea is there
mm, no, there'a problem
but it's a problem with the whole idea, not with the implementation