Erik Erlandson

@soronpo it's here: https://github.com/to-ithaca/libra/blob/master/core/src/main/scala/libra/Fraction.scala https://github.com/to-ithaca/libra/blob/master/core/src/main/scala/libra/ops/fraction.scala

I think we can probably make that work. I've had problems with `inferImplicitValue` in the past, although only in some situations: https://stackoverflow.com/questions/43097790/scala-syntax-tree-returned-from-inferimplicitvalue-is-failing-to-evaluate If it was 2.13+ only, I'd feel pretty...

How does this happen now, with existing singleton types? The case of `1 + 2 + 3` seems like it incurs the same basic structural issue, even if the argument...

Thanks @soronpo! I'll play around with it when I get a chance

@soronpo this looks very cool - so you get the `Out` type by caching the result from "inner" macro calls invoked by the type checking, and then grabbing it out...

interesting, I couldn't figure out how to persuade `inferImplicitValue` come back with an `Out` type I could access Aha, I was trying to use `itree` and `itree.tpe`, not whatever `itree.tpe.decls.head.info`...

I will be very surprised if this doesn't work for Rational, but I'll try it out to make sure

@soronpo I played with an implementation for Rational addition, and confirmed that `OpIntercept` is working like we wanted: ```scala scala> val t = shapeless.the[Rational[1,3] + 2 + Rational[1,6]] t: singleton.ops.impl.OpMacro[singleton.ops.impl.OpId.+,singleton.ops.rational.Rational[1,3]...

> This way we can define any operations on the typelevel on any types and arguments, and also get a term-level composed function. in this concept, is `def apply(args :...

This initial push isn't working. In broad strokes, it seems to be operating the way we were targeting in the #140 discussion: it will attempt to typecheck the `implicitly[OpIntercept ...`...