Newest at the top
| 2025-02-01 03:46:47 +0100 | <euouae> | so what happens with (x :: Int, x :: Int) that still prevents it from being shared? |
| 2025-02-01 03:46:35 +0100 | <EvanR> | or even the same type |
| 2025-02-01 03:46:33 +0100 | <EvanR> | in your example they very well may not be the same value |
| 2025-02-01 03:46:11 +0100 | <EvanR> | then you can share the value |
| 2025-02-01 03:46:08 +0100 | <EvanR> | euouae, for sharing to be possible, the two expressions would have to be known to evaluate to the same value |
| 2025-02-01 03:45:40 +0100 | <int-e> | EvanR: Hmm I suspect it mostly affects optimization. But you can probably construct degenerate examples where type descriptors blow up (you construct an arbitrary sized type descriptor) but the functions associated with the class instances don't. (It's `coerce` all the way.) If you only worry about whether something is a function or not at runtime... no it makes no difference. |
| 2025-02-01 03:45:34 +0100 | <euouae> | so anyway, sharing happens in concrete types? |
| 2025-02-01 03:44:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-01 03:44:28 +0100 | <geekosaur> | because it won't be good enough |
| 2025-02-01 03:44:20 +0100 | <geekosaur> | it should, you will have problems if you insist on "thats good enlugh isnt it?" |
| 2025-02-01 03:44:18 +0100 | <lambdabot> | ‘a0’ arising from a use of ‘show_M13899420735... |
| 2025-02-01 03:44:18 +0100 | <lambdabot> | • Ambiguous type variables ‘m0’, |
| 2025-02-01 03:44:18 +0100 | <lambdabot> | error: |
| 2025-02-01 03:44:17 +0100 | <EvanR> | > fail "monad tutorial failed" |
| 2025-02-01 03:43:57 +0100 | <euouae> | failure does not worry me |
| 2025-02-01 03:43:27 +0100 | <geekosaur> | "interfaces" is a flawed attempt to understand typeclasses in terms of something better known, much like all the failed monad tutorials floating around the internet |
| 2025-02-01 03:43:24 +0100 | <EvanR> | is passing type descriptors tangibly different in practice |
| 2025-02-01 03:42:39 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-02-01 03:42:37 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-02-01 03:42:35 +0100 | <int-e> | (And there are alternatives... notably, JHC passed type descriptors instead.) |
| 2025-02-01 03:42:32 +0100 | <EvanR> | D: |
| 2025-02-01 03:42:26 +0100 | <euouae> | No I just roughly know they have to do with interfaces |
| 2025-02-01 03:42:12 +0100 | <geekosaur> | have you reached typeclasses yet? |
| 2025-02-01 03:42:03 +0100 | <int-e> | (Dictionaries are an implementation detail of type classes.) |
| 2025-02-01 03:41:32 +0100 | <geekosaur> | by the time you apply it to the tuple, it's too late to go back and do sharing. if you specify it in the let, it can share |
| 2025-02-01 03:41:31 +0100 | <euouae> | I haven't heard of dictionary before |
| 2025-02-01 03:41:18 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-02-01 03:41:16 +0100 | <int-e> | Concretely at runtime, the argument is a Num dictionary for p. |
| 2025-02-01 03:41:07 +0100 | <geekosaur> | as long as it has a constraint, it's like a partially applied function. (=> looks like -> for a reason) the thing that needs to be applied is an instance dictionary |
| 2025-02-01 03:40:50 +0100 | <EvanR> | no the => in Num p => p |
| 2025-02-01 03:40:41 +0100 | <euouae> | the `p` argument in Num p => p? |
| 2025-02-01 03:40:37 +0100 | <EvanR> | no |
| 2025-02-01 03:40:30 +0100 | <euouae> | when you say function do you mean type function |
| 2025-02-01 03:39:40 +0100 | <euouae> | it's something more than that |
| 2025-02-01 03:39:38 +0100 | <EvanR> | pair of numbers vs "like a function waiting for two different Num instances, that may or may not happen to be the same instance" |
| 2025-02-01 03:39:25 +0100 | <euouae> | Yeah, `let x = trace "foo" 1 in (x :: Int, x :: Int)` will still print two foos |
| 2025-02-01 03:39:03 +0100 | <int-e> | so it's not *just* type inference |
| 2025-02-01 03:38:54 +0100 | <int-e> | well sharing and lack thereof is firmly a runtime phenomenon |
| 2025-02-01 03:38:53 +0100 | <EvanR> | now it's a pair of numbers |
| 2025-02-01 03:38:48 +0100 | <lambdabot> | (Int, Double) |
| 2025-02-01 03:38:47 +0100 | <EvanR> | :t let y = 1 in (y,y) :: (Int, Double) |
| 2025-02-01 03:38:18 +0100 | <euouae> | because I can do :: (Int, Double) |
| 2025-02-01 03:38:12 +0100 | <euouae> | well, so it is type inference right |
| 2025-02-01 03:37:57 +0100 | <geekosaur> | think about that one for a bit |
| 2025-02-01 03:37:34 +0100 | <lambdabot> | (Num a, Num b) => (a, b) |
| 2025-02-01 03:37:33 +0100 | <geekosaur> | :t let y = 1 in (y,y) |
| 2025-02-01 03:37:24 +0100 | <EvanR> | rather than a number |
| 2025-02-01 03:37:13 +0100 | <EvanR> | 1 is like a function waiting to be given a Num instance |
| 2025-02-01 03:37:09 +0100 | <euouae> | it being Num doesn't tell me much I don't know what to make of it |
| 2025-02-01 03:36:56 +0100 | <lambdabot> | Num p => p |