milessabin/shapeless

shapeless: Generic programming for Scala | This room deprecated in favour of #shapeless on the Typelevel Discord: https://discord.gg/bSQBZA3Ced

Ben Kyrlach

@bkyrlach

I can use implicit ev: SelectAll[H,I] to ensure all members of I are in H.

And I can use implicit ev: IsHCons[I] to ensure that I is not empty.

But if I combine the two like so...

def foo[H <: Hlist, I <: HList](xs: H, ys: I)(implicit ev: SelectAll[H,I], ev2: IsHCons[I]): Unit = {
  println(xs.select[ev2.H])
}

It says that there's no proof that ev2.H is in H.

Gunnar Lilleaasen

@heksesang

@bkyrlach Because ev2 contains proof that I has a head, but not that H has a head, I think.

Gunnar Lilleaasen

@heksesang

And you try to do a select without having a selector.

SelectAll does not guarantee order, so SelectAll[H, I] does not provide proof that IsHCons[I] is equal to IsHCons[H].

Gunnar Lilleaasen

@heksesang

So you cannot do ev2.head(xs) because while they have the same types, it’s not given that the head of H is the same type as head of I. It could be a type not existing in I, or one of the types in the tail of I. And if you wanna do xs.select, you need to provide a Selector instance for it.

Gunnar Lilleaasen

@heksesang

https://scastie.scala-lang.org/eAYPerphTcyXVcBRQEEWdg

Ben Kyrlach

@bkyrlach

I need to digest that a little.

But it looks way better than what I finally arrived at last night.

rquinlivan

@rquinlivan

To me the point of HMap would be to be able to get("key") and get back a strongly typed value instead of Any. If you cannot have polymorphic key mapping then HMap is useless.

Fabio Labella

@SystemFw

but that's what HMap does

or rather, there are two different approaches to this problem: HMap and Vault

rquinlivan

@rquinlivan

No, it gives you a mapping from A -> B and C -> D. Not A ->B and A -> C

Fabio Labella

@SystemFw

HMap is type driven

if you have A -> B and A -> C then by definition it's not a mapping

what does A ->map to, at the type level?

B or C?

rquinlivan

@rquinlivan

As far as practical usefulness, the way HMap is implemented is not useful.

Fabio Labella

@SystemFw

that's untrue, it's just not a good fit (maybe) for your current use case

rquinlivan

@rquinlivan

What is a use case where you would use it as it is implemented?

Fabio Labella

@SystemFw

use objects as your keys

they will all have different types

and it will work brilliantly

you can then convert strings to objects at the edge (or even build some machinery with witness similarly to how record selection works)

again, if you have A -> B and A -> C, how is that a mapping?

Fabio Labella

@SystemFw

btw I think there might be some confusion about the sort of guarantees that you can provide with static types in a language without full dependent types

it sounds like you want to be able to map the value "a" to the type Boolean and the value "b" to the type Int

this is not directly possible without full dependent types: a value is a runtime entity, whilst a type is a compile time one

the way you simulate it generally is by the pattern of creating singleton types

you create types with exactly one value, provide a type to type mapping, and then need to handle the lifting of values to their singleton types with runtime checks (if they aren't statically known) or macros (if they are)

the pattern I mention above with objects as key + HMap does exactly that

and the same pattern is used by shapeless labelled generic, without going through objects but directly exposing the singleton types of strings through macro magic

Fabio Labella

@SystemFw

@rquinlivan

Tim Spence

@TimWSpence

If I have a recursively-resolved typeclass like this:

trait Foo[A] {
  type Repr
  def to: Repr
}

With at most one instance for a given A. Is there a way to write an instance summoner that looks something like this:

def instance[A](implicit foo: Foo.Aux[A,R]): R = ???

? And if so, will the compiler correctly infer the concrete type rather than some Foo.Aux… type?

Fabio Labella

@SystemFw

def instance[A](implicit foo: Foo[A]): foo.Repr = foo

Tim Spence

@TimWSpence

sigh, that was surprisingly obvious! :joy:

Will the compiler infer the concrete type of Foo[A].repr for a given A?

Fabio Labella

@SystemFw

if you've declared things right, yes

Tim Spence

@TimWSpence

:joy: we’ll find out

Thanks Fabio!

Fabio Labella

@SystemFw

:+1: :)

Tim Spence

@TimWSpence

@SystemFw it didn’t work :sob: Any suggestions off the top of your head or shall I try to dump the code in a gist somewhere?

Fabio Labella

@SystemFw

make sure you have an explicit type for your instances, which is Auxed

e.g implicit def yo: Foo.Aux[A, Int]

implicit def yo: Foo[A] won't work (that's what I meant by declaring things right)

if that fails, a small reproducible gist will do

and that means you have a logical error in your derivation somewhere

Where communities thrive

People

Repo info

Activity