HList based tupler

[Fristi]

I've used shapeless' hlist's to build up product types as seen here: https://github.com/Fristi/endpoints-proto/blob/master/algebra/src/main/scala/itinere/Tupler.scala.

Advantages:

• No 22 tuple limit
• We can use the Generic machinery of shapeless to map to case classes

[Krever]

@julienrf Do you think it pays the cost of introducing first dependency to core algebra?

Idea looks interesting and for sure worth investigating but I'm not sure if its beneficial enough. Mapping to case classes may be a really nice feature though.

I had a different idea at some point, to remove tupler at all. User then has to deal with Units but it would simplify the api a lot.

[julienrf]

In the beginning I considered using shapeless’ HList instead of tuples but I thought it was not worth introducing a dependency on shapeless just to get an HList definition (we use no operations on HList and no feature of shapeless). But in practice I often have shapeless in my classpath anyway because I do typeclass derivation in some places. So, why not use shapeless’ HList instead of tuples, if that also makes life easier for case classes mapping.

Note that it should still be possible to map to case classes without introducing shapeless in the core, but at the (cheap) cost of an additional implicit parameter.

[julienrf]

One advantage of using tuples is that the syntax to “call” an endpoint is very similar to calling a method with several parameters (excepted that it’s a single tuple parameter):

val foo: Endpoint[(Int, String), Int] = …
foo((42, "bar"))

On the other hand, if we use HLists we will have to write the following:

val foo: Endpoint[Int :: String :: HNil, Int] = …
foo(42 :: "bar" :: HNil)

Which is less nice imho. We could support passing a tuple as parameter as well, by having an apply method taking an implicit Generic that would convert the tuple into the expected HList but then error messages in case of type mismatch will be disguised into “implicit not found” errors :(

[julienrf]

I think we should wait for Scala 3 to implement this feature. In Scala 3, tuples can be used like Shapeless’ HLists.

[harpocrates]

Scala 3 tuples will indeed be nice. However, I'm not sure what the migration plan might be here, since the behaviour of Scala 3 Tupler instances would be different than the Scala 2 ones (eg. they'd be able to concatenate larger tuples). That might be a bit frustrating for projects that cross-build for a while and need the same Scala code to work across both versions.

As such, perhaps it makes sense to add an HList based Tupler now to Scala 2 (then the Shapeless dependency can be removed for the Scala 3 build since the same instances will be achievable directly with native tuples). Just to be clear: this would not mean writing val foo: Endpoint[Int :: String :: HNil, Int] = - it would just mean that the following would work on 2 via Shapeless and on 3 via native tuples.

trait MyEndpoints extends endpoints4s.algebra.Endpoints {
  def tooManyArgs: Endpoint[(Int, Int, Int, Int, Int, Int), Unit] = endpoint(
    request = post(
      url = path / "foo" / segment[Int]("i1") / segment[Int]("i2") / segment[Int]("i3"),
      entity = emptyRequest.xmap(_ => (0,1,2))(_ => ())
    ),
    response = ok(emptyResponse)
  )
}

... instead of failing with the type error

cmd3.sc:3: type mismatch;
 found   : MyEndpoints.this.Request[this.Out]
    (which expands to)  MyEndpoints.this.Request[(Int, Int, Int, (Int, Int, Int))]
 required: MyEndpoints.this.Request[(Int, Int, Int, Int, Int, Int)]
Error occurred in an application involving default arguments.
    request = post(
                  ^
Compilation Failed

[julienrf]

it would just mean that the following would work on 2.12 via Shapeless and on 2.13 via native tuples.

I guess you mean “on Scala 2 via Shapeless and on Scala 3 via native tuples”. Did you make some experiments to check that the user experience would be good on Scala 2?

[harpocrates]

Yes, that’s what I meant. I haven’t yet check the user experience - I want to first see if there was already another plan in place before investigating. I suspect the user experience wouldn’t be too different: all that would change is the method by which the tupler implicit is resolved (so the only error message users should see is the same implicit not found one they would see before). When I have some time, I’ll try to implement both the Scala 2 and Scala 3 parts of this.

…

Sent from my iPhone

On Aug 15, 2020, at 16:17, Julien Richard-Foy ***@***.***> wrote:  it would just mean that the following would work on 2.12 via Shapeless and on 2.13 via native tuples. I guess you mean “on Scala 2 via Shapeless and on Scala 3 via native tuples”. Did you make some experiments to check that the user experience would be good on Scala 2? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.