Newest at the top
2024-12-29 01:02:54 +0100 | <geekosaur> | (meaning i, j, k are the key types since those specify the Ord instances, again AIUI) |
2024-12-29 01:02:18 +0100 | <geekosaur> | (since one of the uses of indexed monads is to allow things like an indexed monad instance for Set, which normally isn't possible because changing the key type alters the structure to reflect a different Ord instance. AIUI at least) |
2024-12-29 01:01:59 +0100 | gentauro | (~gentauro@user/gentauro) gentauro |
2024-12-29 01:01:27 +0100 | lol_ | jcarpenter2 |
2024-12-29 01:00:36 +0100 | foul_owl | (~kerry@174-21-81-201.tukw.qwest.net) foul_owl |
2024-12-29 01:00:21 +0100 | <geekosaur> | so it tracks the original and final Ord instances |
2024-12-29 00:59:55 +0100 | <geekosaur> | think a and b having different Ord instances |
2024-12-29 00:59:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-12-29 00:56:00 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
2024-12-29 00:55:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-29 00:54:22 +0100 | <haskellbridge> | <thirdofmay18081814goya> you'll want two indexed* |
2024-12-29 00:54:10 +0100 | <haskellbridge> | <thirdofmay18081814goya> hm but maybe you'll two indexes if you're mapping from lists of length n to lists of length m? |
2024-12-29 00:53:11 +0100 | <haskellbridge> | <thirdofmay18081814goya> the usage of one index is understandable, e.g. the type of lists with a given length |
2024-12-29 00:52:35 +0100 | <haskellbridge> | <thirdofmay18081814goya> next question is... why two indexes? |
2024-12-29 00:48:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-12-29 00:47:51 +0100 | <haskellbridge> | <thirdofmay18081814goya> was reading that wrong |
2024-12-29 00:47:36 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
2024-12-29 00:46:55 +0100 | <haskellbridge> | <thirdofmay18081814goya> they are from the same indexing type* |
2024-12-29 00:45:37 +0100 | foul_owl | (~kerry@193.42.0.124) (Ping timeout: 252 seconds) |
2024-12-29 00:43:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-29 00:39:35 +0100 | <haskellbridge> | <thirdofmay18081814goya> ok right, I wasn't quite getting that in "m i j a", both "i" and "j" are indextypes |
2024-12-29 00:35:40 +0100 | <geekosaur> | AIUI the whole point is that the indexed monad tracks an initial and a final index. individual actions within it produce new "final" indexes which aren't the final index of the entire computation because the next action maps from the first "final" index to a new one |
2024-12-29 00:33:42 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
2024-12-29 00:33:21 +0100 | <geekosaur> | there isn't much to think about, any more than it's worth thinking about 2+3+4 giving you an intermediate 5 |
2024-12-29 00:33:13 +0100 | <haskellbridge> | <thirdofmay18081814goya> that makes more sense, ok ty |
2024-12-29 00:33:10 +0100 | <haskellbridge> | <thirdofmay18081814goya> right ok |
2024-12-29 00:32:41 +0100 | <haskellbridge> | <thirdofmay18081814goya> hm I'll think about the idea of discarding the intermediate index type, ty |
2024-12-29 00:32:01 +0100 | <geekosaur> | the initial state encodes i->j, then the action gives you j->k, meaning the result is i->k |
2024-12-29 00:30:30 +0100 | <geekosaur> | looks like a straightforward generalization of (a -> m b) -> m a -> m b, with an assumption that the action produces both a new value type and a new index type to go with it, and the result type encodes the initial and final index types while discarding the intermediate one (j) because it becomes k when the action is run |
2024-12-29 00:30:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-12-29 00:26:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2024-12-29 00:26:21 +0100 | <haskellbridge> | <thirdofmay18081814goya> I'm reading "m i j a" as, the monad indexed by "i", such that "j" depends on "i" |
2024-12-29 00:26:13 +0100 | housemate | (~housemate@pa49-185-30-217.pa.vic.optusnet.com.au) (Ping timeout: 248 seconds) |
2024-12-29 00:25:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-29 00:24:35 +0100 | <haskellbridge> | <thirdofmay18081814goya> "(a -> m j k b) -> m i j a -> m i k b", the two last types makes sense, but the first type "(a -> m j k b)" I'm not too sure about |
2024-12-29 00:23:44 +0100 | <haskellbridge> | <thirdofmay18081814goya> hm, anyone has some insight about why the indexed monad's "bind" has that type? |
2024-12-29 00:13:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
2024-12-29 00:12:54 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 260 seconds) |
2024-12-29 00:11:07 +0100 | Xe | (~Xe@perl/impostor/xe) Xe |
2024-12-29 00:10:10 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2024-12-29 00:09:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-29 00:05:02 +0100 | cowboy8625 | (~cowboy@2605-4A80-7405-640-B51A-FA7D-9084-E360-dynamic.midco.net) |
2024-12-28 23:57:52 +0100 | <hololeap> | ok, because I didn't see any connection to resetT and shiftT, but I wasn't sure |
2024-12-28 23:56:53 +0100 | <geekosaur> | I want to say you've reinvented CPS, rather than ContT as such |
2024-12-28 23:56:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-12-28 23:56:16 +0100 | housemate | (~housemate@pa49-185-30-217.pa.vic.optusnet.com.au) housemate |
2024-12-28 23:55:27 +0100 | <hololeap> | am I reinventing ContT or is this something else? |
2024-12-28 23:54:33 +0100 | <hololeap> | runLoop loop = loop (updateAndContinue loop) |
2024-12-28 23:54:29 +0100 | <hololeap> | runLoop :: UpdaterLoop m -> m () |
2024-12-28 23:54:22 +0100 | <hololeap> | I have this: UpdaterLoop m = m () -> m () |