Newest at the top
| 2025-02-01 03:52:34 +0100 | <EvanR> | otherwise D: |
| 2025-02-01 03:52:23 +0100 | <EvanR> | you're in good shape if you don't care about sharing xD |
| 2025-02-01 03:50:59 +0100 | <euouae> | thank you |
| 2025-02-01 03:50:25 +0100 | <EvanR> | and then sharing would be an optimization on top of that |
| 2025-02-01 03:49:29 +0100 | <EvanR> | x::Int |
| 2025-02-01 03:49:25 +0100 | <euouae> | ah I see. What is the subexpression? the x in the tuple? |
| 2025-02-01 03:49:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-01 03:49:14 +0100 | <EvanR> | CSE could make let x = 1 in (x::Int,x::Int) into let x = 1 :: Int in (x,x) |
| 2025-02-01 03:48:50 +0100 | <geekosaur> | "common subexpression elimination" |
| 2025-02-01 03:48:45 +0100 | <int-e> | in your context, which is GHCi (so unoptimized bytecode) |
| 2025-02-01 03:48:39 +0100 | <euouae> | not sure what CSE is |
| 2025-02-01 03:48:31 +0100 | <EvanR> | oh that's why |
| 2025-02-01 03:48:24 +0100 | <int-e> | euouae: there's *no* CSE |
| 2025-02-01 03:48:12 +0100 | <euouae> | right but is there some deeper understanding to draw from that geekosaur ? |
| 2025-02-01 03:48:09 +0100 | <geekosaur> | because they might not be the same type when applied |
| 2025-02-01 03:47:50 +0100 | <geekosaur> | as I said earlier, if you make them both Int when you are tupling them, it's too late; the decision was made that it couldn't share them |
| 2025-02-01 03:47:46 +0100 | <EvanR> | but doesn't? |
| 2025-02-01 03:47:40 +0100 | <EvanR> | presumably a smart enough compiler could look at (x :: Int, x :: Int) and deduce they must evaluate to the same thing |
| 2025-02-01 03:47:08 +0100 | <EvanR> | x was a polymorphic thing waiting to be told what Num instance to use |
| 2025-02-01 03:47:05 +0100 | <euouae> | that x::Int is unevaluated while x::Int evaluates to `x` (but Int now) and then _that_ thunk gets shared? |
| 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 |