Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 31 05:54
    pgrandjean opened #1265
  • Jul 31 05:51
    pgrandjean opened #1264
  • Jul 22 14:26
    joroKr21 commented #1200
  • Jul 22 14:22
    SethTisue commented #1200
  • Jul 22 13:18
    Katrix synchronize #1200
  • Jul 20 09:56

    joroKr21 on main

    Remove refinement from Witness.… Merge branch 'main' into witnes… Merge branch 'main' into witnes… and 2 more (compare)

  • Jul 20 09:56
    joroKr21 closed #1240
  • Jul 20 09:10
    milessabin commented #1240
  • Jul 19 17:41
    joroKr21 commented #1240
  • Jul 19 17:41
    joroKr21 synchronize #1240
  • Jul 14 05:59

    joroKr21 on main

    Update sbt to 1.7.1 Merge pull request #1263 from s… (compare)

  • Jul 14 05:59
    joroKr21 closed #1263
  • Jul 13 23:00
    scala-steward opened #1263
  • Jul 10 12:03

    joroKr21 on main

    Update junit-plugin, junit-runt… Revert commit(s) ca4fe1de Merge branch 'main' into update… and 2 more (compare)

  • Jul 10 12:03
    joroKr21 closed #1262
  • Jul 09 23:27
    scala-steward synchronize #1262
  • Jul 08 08:18

    joroKr21 on main

    Update sbt-scalajs, scalajs-com… Merge branch 'main' into update… Merge pull request #1260 from s… (compare)

  • Jul 08 08:18
    joroKr21 closed #1260
  • Jul 08 08:06
    joroKr21 synchronize #1260
  • Jul 08 08:06

    joroKr21 on main

    Update scala-compiler, scala-li… Merge pull request #1261 from s… (compare)

Fabio Labella
@SystemFw
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
Tim Spence
@TimWSpence
Cool, thanks!
Miles Sabin
@milessabin
Aux is the way to go.
It's still needed in Dotty I'm afraid.
It would be good to come up with a way to avoid it.
Fabio Labella
@SystemFw
I'm actually worried about how obscure things will be with the new given syntax and so on
we don't need Aux as much though, right? if parameters can depend on each other within lists
Miles Sabin
@milessabin
There's that. But the other use of Aux to abbreviate duplicated type member declarations in result types doesn't go away.
Fabio Labella
@SystemFw
yeah that makes sense
however perhaps you can just write the full refinement in that case, it's not that big of a deal if only the return type is affected. I think what confuses people about Aux is the prolog style it forces when thinking about your type params, mostly
and that is fixed if you can do (implicit gen: Generic[A], foo: Foo[gen.Repr])
although again, I wonder how that works with the new syntax
Tim Spence
@TimWSpence
Thanks @SystemFw and @milessabin - it (finally) worked! :)
Miles Sabin
@milessabin

although again, I wonder how that works with the new syntax

I'd need to check, but I'm pretty sure it works in much the same way.

Fabio Labella
@SystemFw
:+1:
Ben Kyrlach
@bkyrlach

With the help of the kind folks on here, I finally got some code that works. If anyone was extremely bored and wanted to provide some feedback, I'm sure there's plenty of improvements that could be made.

https://gist.github.com/bkyrlach/cf8ea12ded3c6fb07c14d9c00b33a818
https://gist.github.com/bkyrlach/2ba7fcad87e780e9958c34f898beb468

PhillHenry
@PhillHenry

I suspect this is a silly question: it appears that the values given to create a shapeless.Sized need to be explicitly typed in by the programmer. Is there any way to make this more flexible - perhaps with values pulled from a more dynamic source...?

I'm guessing the answer is 'no' but since Shapeless does things I never thought would be possible, it's worth asking the question.

Fabio Labella
@SystemFw
the answer is no