Logs: freenode/#haskell
| 2021-03-27 18:09:33 | <curl> | :t mapAccumL |
| 2021-03-27 18:09:35 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2021-03-27 18:09:47 | <curl> | they are all these things of type (a -> b -> (a, c)) |
| 2021-03-27 18:10:06 | <curl> | `a' is acting as the state there |
| 2021-03-27 18:10:44 | <curl> | though i prefer (i -> s -> (o,s)) = State s i o |
| 2021-03-27 18:11:28 | <curl> | the proposal is there should be some kind of fusion for states being sequentially composed down into an unfold |
| 2021-03-27 18:11:59 | <curl> | i guess this already happens with Traversable somehow |
| 2021-03-27 18:12:06 | <ephemient> | > let (_, fib) = mapAccumL (\a b -> (a + b, a)) 1 (0:fib) in 0:fib |
| 2021-03-27 18:12:08 | <lambdabot> | [0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,... |
| 2021-03-27 18:12:20 | <__minoru__shirae> | curl: "one element at a time" - in haskell you don't have to build the whole list to start handling its elements |
| 2021-03-27 18:12:35 | <curl> | its a notion embodied in the fusion |
| 2021-03-27 18:12:42 | <curl> | its how you can get it down to an unfold |
| 2021-03-27 18:13:11 | × | ddellacosta quits (~ddellacos@86.106.143.27) (Ping timeout: 240 seconds) |
| 2021-03-27 18:13:19 | <curl> | you think of the sequence of composed states processing one value at a time, and this sequence being composed down to one action by the fusion |
| 2021-03-27 18:13:31 | <ephemient> | > unfoldr (Just . \(a, b) -> (a, (b, a + b))) (0, 1) |
| 2021-03-27 18:13:33 | <lambdabot> | [0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,... |
| 2021-03-27 18:14:06 | × | dxld quits (~dxld@rush.pub.dxld.at) (Ping timeout: 245 seconds) |
| 2021-03-27 18:14:23 | <curl> | right, you should alsways be able to rewrite any mapAccumL over any unfolded list, into just one unfold |
| 2021-03-27 18:14:45 | <__minoru__shirae> | curl: you mean functions with signature "a -> m ()", right? |
| 2021-03-27 18:14:55 | <curl> | no... |
| 2021-03-27 18:15:05 | <curl> | not sure where you got that from |
| 2021-03-27 18:15:22 | <__minoru__shirae> | curl: "you think of the sequence of composed states processing one value at a time, and this sequence being composed down to one action by the fusion" |
| 2021-03-27 18:15:28 | → | knupfer joins (~Thunderbi@dynamic-046-114-151-080.46.114.pool.telefonica.de) |
| 2021-03-27 18:15:39 | → | dxld joins (~dxld@rush.pub.dxld.at) |
| 2021-03-27 18:15:41 | <__minoru__shirae> | what is the signature of that action? |
| 2021-03-27 18:15:54 | <curl> | well just one state i guess |
| 2021-03-27 18:16:12 | <curl> | states i was writing (i -> s -> (o,s)) |
| 2021-03-27 18:16:18 | × | dyeplexer quits (~lol@unaffiliated/terpin) (Remote host closed the connection) |
| 2021-03-27 18:16:21 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 268 seconds) |
| 2021-03-27 18:16:50 | <curl> | which is backwards of how they appear in mapAccumL as (a -> b -> (a,c)) |
| 2021-03-27 18:17:02 | <curl> | :t mapAccumL |
| 2021-03-27 18:17:04 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2021-03-27 18:17:53 | → | e joins (e@freenode/staff/spy.edk) |
| 2021-03-27 18:18:24 | <curl> | basically you have a bunch of i's and o's that have to match up, and a bunch of s's which are grouped together into one effective state |
| 2021-03-27 18:18:55 | → | codygman__ joins (~user@47.186.207.161) |
| 2021-03-27 18:18:56 | → | Sornaensis joins (~Sornaensi@185.217.117.65) |
| 2021-03-27 18:18:59 | × | tromp quits (~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection) |
| 2021-03-27 18:20:18 | <curl> | like, 2 mapAccumL in series is like one with the pair of the states of each as its state |
| 2021-03-27 18:21:55 | <curl> | anyway, even if you dont think of the elements being processed one at a time going through the states, the states still end up in a list more or less, so there is still the idea of this processor that the elements are being fed through |
| 2021-03-27 18:22:26 | → | danvet joins (~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa) |
| 2021-03-27 18:22:28 | <curl> | i guess i should distinguish between states and state functions... |
| 2021-03-27 18:22:38 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 240 seconds) |
| 2021-03-27 18:22:41 | × | Sorny quits (~Sornaensi@077213203030.dynamic.telenor.dk) (Ping timeout: 265 seconds) |
| 2021-03-27 18:22:45 | <curl> | states s, state function i -> s -> (o,s) |
| 2021-03-27 18:23:25 | <monochrom> | Perhaps you like "state transition function". |
| 2021-03-27 18:23:26 | <curl> | a sequence of state functions becomes a state function with a list of states as its state |
| 2021-03-27 18:23:31 | <__minoru__shirae> | how about the obvisous solution, calling mapAccumL, then taking its result and then calling the next mapAccumL on it |
| 2021-03-27 18:23:50 | <curl> | yeah thats how they compose |
| 2021-03-27 18:23:55 | <curl> | in sequence or series |
| 2021-03-27 18:24:33 | <curl> | so mapAccumL takes both the state function and the state and then is a function in one argument ready for sequential composition |
| 2021-03-27 18:24:34 | <monochrom> | If you re-imagine the "a -> t b -> (a, t c)" part to be "(a, t b) -> (a, t c)", you can use vanilla "." for chaining. |
| 2021-03-27 18:25:24 | <curl> | an uncurried state function |
| 2021-03-27 18:25:34 | <curl> | fine |
| 2021-03-27 18:25:37 | × | zebrag quits (~inkbottle@aaubervilliers-654-1-98-245.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!) |
| 2021-03-27 18:25:58 | → | zebrag joins (~inkbottle@aaubervilliers-654-1-98-245.w86-212.abo.wanadoo.fr) |
| 2021-03-27 18:26:09 | <curl> | so then each state and state function together, with mapAccumL partially applied, all dotted together |
| 2021-03-27 18:26:21 | <__minoru__shirae> | using this approach you can build one chain of handlers, how about linking those chains into trees? |
| 2021-03-27 18:26:21 | <curl> | and that should be with a rewrite to an unfold |
| 2021-03-27 18:26:54 | × | NinjaTrappeur quits (~ninja@2001:913:5200:200::) (Quit: WeeChat 3.1) |
| 2021-03-27 18:26:56 | <curl> | and that would be inductivly written just needing to match one dot to then work on any number in a sequence |
| 2021-03-27 18:27:13 | → | NinjaTrappeur joins (~ninja@unaffiliated/ninjatrappeur) |
| 2021-03-27 18:27:14 | → | madjestic joins (~Android@86-88-72-244.fixed.kpn.net) |
| 2021-03-27 18:27:18 | <curl> | __minoru__shirae: trees of outputs or inputs or both? |
| 2021-03-27 18:27:19 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:16f:a8e3:b3e2:cec6) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-03-27 18:27:42 | <__minoru__shirae> | I mean graphs of processing steps |
| 2021-03-27 18:27:51 | <curl> | in either case you output or have input of pairs or lists |
| 2021-03-27 18:28:08 | <curl> | as edges to the consequent verticies |
| 2021-03-27 18:28:40 | × | geowiesnot quits (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 268 seconds) |
| 2021-03-27 18:28:44 | <curl> | lists of outputs or inputs, not trees, sorry |
| 2021-03-27 18:28:55 | <curl> | but that ends up like a tree |
| 2021-03-27 18:29:07 | → | stree joins (~stree@68.36.8.116) |
| 2021-03-27 18:29:20 | <curl> | very difficult |
| 2021-03-27 18:29:31 | <curl> | impossible to have both branching outputs and inputs |
| 2021-03-27 18:29:40 | <curl> | makes a graph that cant be easily represented in haskell |
| 2021-03-27 18:29:43 | <curl> | big problem |
| 2021-03-27 18:29:51 | <curl> | no solution as yet |
| 2021-03-27 18:29:52 | <__minoru__shirae> | and siblings just call mapAccumL on the same input independently of each other, right? |
| 2021-03-27 18:30:01 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:16f:a8e3:b3e2:cec6) |
| 2021-03-27 18:30:09 | × | jess quits (jess@freenode/staff/jess) () |
| 2021-03-27 18:30:23 | <curl> | the states are kept separate yes |
| 2021-03-27 18:30:23 | × | coot quits (~coot@37.30.55.131.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2021-03-27 18:30:32 | <curl> | they just kind of sit over the nodes in the graph |
| 2021-03-27 18:30:40 | <curl> | inputs and outputs as edges between |
| 2021-03-27 18:31:07 | <curl> | there must be some zipping |
| 2021-03-27 18:31:19 | <curl> | you would have to do that with type level lengths |
| 2021-03-27 18:31:32 | <curl> | since you would be zipping up into a list not a tuple |
| 2021-03-27 18:31:57 | <curl> | so the mapAccumL can opperate on just one list from a list of inputs |
| 2021-03-27 18:32:22 | <curl> | many input edges in a list, each having a list to stream over |
| 2021-03-27 18:32:38 | <curl> | so you zip them up and stream over them |
| 2021-03-27 18:32:52 | → | tromp joins (~tromp@dhcp-077-249-230-040.chello.nl) |
| 2021-03-27 18:32:54 | <curl> | but at the outputs its more complicated, since you have to unzip them and send them to the correct place |
| 2021-03-27 18:33:38 | → | star_cloud joins (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) |
| 2021-03-27 18:33:52 | <curl> | which requires representation of a graph |
| 2021-03-27 18:34:15 | <curl> | which you cant do in GADTs like you can Trees |
| 2021-03-27 18:34:30 | <curl> | "upwards edges" being unrepresentable |
| 2021-03-27 18:34:45 | <curl> | only branches below so to speak |
| 2021-03-27 18:35:29 | → | jb55 joins (~jb55@gateway/tor-sasl/jb55) |
| 2021-03-27 18:36:34 | <curl> | you can fan out easily though, with no recombination, no lists as inputs, so that lists of outputs are only ever acted on by unique consumers |
| 2021-03-27 18:37:08 | × | codygman__ quits (~user@47.186.207.161) (Remote host closed the connection) |
| 2021-03-27 18:37:32 | → | codygman__ joins (~user@47.186.207.161) |
All times are in UTC.