Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 29 20:39

    joroKr21 on main

    Update sbt-scalajs, scalajs-com… (compare)

  • Jan 29 20:39
    joroKr21 closed #1297
  • Jan 29 20:31
    joroKr21 synchronize #1297
  • Jan 29 20:30

    joroKr21 on main

    Update scala-parser-combinators… (compare)

  • Jan 29 20:30
    joroKr21 closed #1298
  • Jan 29 19:41
    joroKr21 synchronize #1298
  • Jan 29 19:41

    joroKr21 on main

    Update junit-plugin, junit-runt… (compare)

  • Jan 29 19:41
    joroKr21 closed #1299
  • Jan 29 19:14
    scala-steward opened #1299
  • Jan 27 20:05
    scala-steward opened #1298
  • Jan 27 20:05
    scala-steward opened #1297
  • Jan 07 17:55

    joroKr21 on main

    Update sbt to 1.8.2 (#1296) (compare)

  • Jan 07 17:55
    joroKr21 closed #1296
  • Jan 07 00:30
    DmytroMitin commented #1285
  • Jan 05 17:36
    scala-steward opened #1296
  • Dec 28 2022 14:35

    joroKr21 on main

    Fixed typo (#1295) (compare)

  • Dec 28 2022 14:35
    joroKr21 closed #1295
  • Dec 28 2022 07:13
    windymelt opened #1295
  • Dec 15 2022 20:59

    joroKr21 on main

    Update slf4j-nop to 2.0.6 (#129… (compare)

  • Dec 15 2022 20:59
    joroKr21 closed #1294
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
Tim Spence
@TimWSpence
Oh that could be it! My instances are just typed Foo[String] etc
Fabio Labella
@SystemFw
yeah, you are losing your refinements
a very simple way to fix it is to remove the type sigs
however , that can hit some weird corner cases
so explicit types with Aux is the best practice
Tim Spence
@TimWSpence
Are implicits with no explicit type annotation eligible for this stuff? I thought they weren’t valid as implicit arguments
Fabio Labella
@SystemFw
they are eligible and valid
the inferred type will infer the refinement
the problem is that you hit some bugs sometimes (pretty weird ones)
probably dotty will require explicit signatures for implicits though