I think that the foldr allows you to preserve the order while using (::) rather than (++). It's possible I should just be using Array rather than List, but I don't have a good sense as to which is more efficient in any case. I think that the more general takeaway is that we need to be careful when using stateful transducers.
Thanks for elm-transducers...I'm only using it for toy examples as I'm just learning Elm, but it did simply my "bowling kata" (http://codingdojo.org/cgi-bin/index.pl?KataBowling). Thanks again! Marshall On Sunday, December 18, 2016 at 10:33:20 PM UTC-5, Aaron VonderHaar wrote: > > Hello, I'm the author of elm-transducers, and I will note that I haven't > used in an actual project, nor have I heard of many people using it. So > it's certainly possible that there could be bug in the elm-transducers > package. > > The code you mentioned: > > transduceList = transduce List.foldr (::) [] > > does look unexpected; on reading that, I would expect foldl to be used > there instead. Unfortunately I don't remember if there was a reason I used > foldr. But I do remember that the test cases I used when developing it > were pretty thin since my focus at the time was getting the types to work. > > On Sun, Dec 18, 2016 at 7:06 PM, Marshall handheld Flax < > [email protected] <javascript:>> wrote: > >> Here's code that has a working "transduceList" variant that uses >> "List.foldl", but all of the List.reverse calls doesn't smell nice. (Full >> context at >> https://github.com/marshallflax/lexical-elm/blob/master/src/BowlingScore.elm). >> >> Any suggestions welcome! >> >> transduceListL : Transducer a b (List b) s -> List a -> List b >> transduceListL xform list = >> (transduce List.foldl (::) []) xform list |> List.reverse >> >> partitionBy : (List a -> Bool) -> Transducer a (List a) r (List a) >> partitionBy pred = >> { init = >> \reduce r -> ( [], r ) >> , step = >> \reduce input ( hold, r ) -> >> let >> merged = >> input :: hold >> in >> if (pred merged) then >> ( [], reduce (List.reverse merged) r ) >> else >> ( merged, r ) >> , complete = >> \reduce ( hold, r ) -> >> if (List.isEmpty hold) then >> r >> else >> reduce (List.reverse hold) r >> } >> >> Thanks again! >> >> Marshall >> >> >> >> On Sunday, December 18, 2016 at 9:06:37 PM UTC-5, Marshall handheld Flax >> wrote: >>> >>> Suppose I have a *stateful* transducer >>> >>> partitionBy : (List a -> Bool) -> Transducer a (List a) r (List a) >>> partitionBy pred = >>> { init = >>> \reduce r -> ( [], r ) >>> , step = >>> \reduce input ( hold, r ) -> >>> let >>> merged = >>> input :: hold >>> in >>> if (pred merged) then >>> ( [], reduce merged r ) >>> else >>> ( merged, r ) >>> , complete = >>> \reduce ( hold, r ) -> >>> if (List.isEmpty hold) then >>> r >>> else >>> reduce hold r >>> } >>> >>> >>> that "chunkfies" an input stream input into lists, where the supplid >>> predicate (List a -> Bool) determines when to start the next sublist. (My >>> particular toy application is the standard "Bowling Kata" in which I need >>> to partition a stream of bowling throws into frames, but I think it could >>> be generally useful.) >>> >>> However, the "foldr" in the standard >>> >>> transduceList : Transducer a b (List b) s -> List a -> List b >>> >>> transduceList = >>> >>> transduce List.foldr (::) [] >>> >>> means that the stateful processing occurs from the end, which is exactly >>> the opposite from what I need. (Since I need my state to be dependent upon >>> *earlier* messages, rather than *later* messages). >>> >>> >>> Am I making too much of this (i.e. should just use transduceArray and be >>> done with it)? Or is there something problematic about stateful >>> transducers, in that different "folder" can result in different semantics? >>> >>> >>> Thanks! >>> >>> Marshall >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
