Newest at the top
| 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 |
| 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 |