Comments on: Design your functions for partial application http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/ Bryan O'Sullivan's blog Wed, 08 Feb 2012 06:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Pete http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-127631 Pete Tue, 26 Feb 2008 02:49:21 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-127631 Putting the 'target' element last makes them easier to use with higher order state-manipulating functions like 'gets' and 'modify'. Suppose you have a class of monads with a stack state; then you get mpush = modify . push or in pointy style, mpush x = modify (push x). If you put the target first, you need a flip in both cases. Just my 2p... (or maybe that should be 1p at today's exchange rates ;) Putting the ‘target’ element last makes them easier to use with higher order state-manipulating functions like ‘gets’ and ‘modify’. Suppose you have a class of monads with a stack state; then you get mpush = modify . push or in pointy style, mpush x = modify (push x). If you put the target first, you need a flip in both cases.

Just my 2p… (or maybe that should be 1p at today’s exchange rates ;)

]]> By: Pseudonym http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109263 Pseudonym Thu, 27 Dec 2007 14:39:16 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109263 Incidentally, "insert" also follows the least-varying-argument-first rule (what I call "de Bruijn-like ordering"). After all, it works by induction on the dictionary data structure. That's the argument that varies the most. Incidentally, “insert” also follows the least-varying-argument-first rule (what I call “de Bruijn-like ordering”). After all, it works by induction on the dictionary data structure. That’s the argument that varies the most.

]]> By: Kenn Knowles http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109166 Kenn Knowles Thu, 27 Dec 2007 05:03:59 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109166 OCaml solves this with labeled arguments; do these interact badly with Haskell's features? I'm not sure. Perhaps extensible record encodings allow you to fake it somewhat. OCaml solves this with labeled arguments; do these interact badly with Haskell’s features? I’m not sure. Perhaps extensible record encodings allow you to fake it somewhat.

]]> By: Tom Moertel http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109124 Tom Moertel Wed, 26 Dec 2007 23:26:00 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109124 Yes, having the map as the final argument to map-"mutating" functions means you'll have to use a flip now and then to make things foldl' friendly, but is that really too high a price to pay for logical consistency with the other common container interfaces? In the case of Data.Map's interface, you'll almost never want to reuse a partially applied "mutating" function, such as insert; they are effectively one-time-use calls for each map-key-value triple. (The only common exception is to specialize on the value, such as when using (flip (insertWith (+)) 1) to count keys.) Thus every call is likely to require new values for all three arguments, and no argument ordering is going to be optimal for all scenarios. For foldl'-driven scenarios, having the map as the first argument is certainly convenient, but then again it's pretty easy to define: ffoldl' f = foldl' (flip f) and use it whenever you want foldl' semantics but the accumulator as the 2nd argument. To use your scenario, for example: buildMap = ffoldl' (maybe id (uncurry M.insert)) M.empty . map packageInfo . lines Cheers! --Tom Yes, having the map as the final argument to map-”mutating” functions means you’ll have to use a flip now and then to make things foldl’ friendly, but is that really too high a price to pay for logical consistency with the other common container interfaces?

In the case of Data.Map’s interface, you’ll almost never want to reuse a partially applied “mutating” function, such as insert; they are effectively one-time-use calls for each map-key-value triple. (The only common exception is to specialize on the value, such as when using (flip (insertWith (+)) 1) to count keys.) Thus every call is likely to require new values for all three arguments, and no argument ordering is going to be optimal for all scenarios. For foldl’-driven scenarios, having the map as the first argument is certainly convenient, but then again it’s pretty easy to define:

ffoldl’ f = foldl’ (flip f)

and use it whenever you want foldl’ semantics but the accumulator as the 2nd argument. To use your scenario, for example:

buildMap = ffoldl’ (maybe id (uncurry M.insert)) M.empty . map packageInfo . lines

Cheers! –Tom

]]> By: Bryan O'Sullivan http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109117 Bryan O'Sullivan Wed, 26 Dec 2007 22:00:07 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109117 sclv, fusion doesn't really have anything to do with the space leakage issue. The problem is that using foldr builds up a big unevaluated chain of thunks like so: M.insert k1 v1 (M.insert k2 v2 (M.insert k3 v3 ... M.empty))) Using foldl' instead causes the accumulator to be evaluated to WHNF at each step. sclv, fusion doesn’t really have anything to do with the space leakage issue. The problem is that using foldr builds up a big unevaluated chain of thunks like so:

M.insert k1 v1 (M.insert k2 v2 (M.insert k3 v3 … M.empty)))

Using foldl’ instead causes the accumulator to be evaluated to WHNF at each step.

]]> By: Bryan O'Sullivan http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109111 Bryan O'Sullivan Wed, 26 Dec 2007 21:02:22 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109111 Daniel, filter and map follow my general prescription by placing the less frequently varying argument first. As for your suggested use of insert, it just doesn't arise much in practice, so why design the API with that in mind? Regarding your broader point, you'll notice that where you say there's no golden rule, I mentioned the element of judgment and experience. I believe we're actually somewhat in agreement. Daniel, filter and map follow my general prescription by placing the less frequently varying argument first.

As for your suggested use of insert, it just doesn’t arise much in practice, so why design the API with that in mind?

Regarding your broader point, you’ll notice that where you say there’s no golden rule, I mentioned the element of judgment and experience. I believe we’re actually somewhat in agreement.

]]> By: sclv http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109110 sclv Wed, 26 Dec 2007 20:56:32 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109110 Foldr should also get you fusion in this case though, no? In any case, is buildMap = foldl' (flip $ uncurry M.insert) M.empty . catMaybes . map packageInfo . lines really all *that* bad? Especially since catMaybes should get you some fusion as well. Foldr should also get you fusion in this case though, no?

In any case, is

buildMap = foldl’ (flip $ uncurry M.insert) M.empty . catMaybes . map packageInfo . lines

really all *that* bad? Especially since catMaybes should get you some fusion as well.

]]> By: Daniel Yokomizo http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109109 Daniel Yokomizo Wed, 26 Dec 2007 20:52:46 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109109 What if I want to write: insert k1 v1 $ insert k2 v2 $ insert k3 v3 map The order for insert is the same used for filter, map & friends, with the container in the end. Searching on the mailing lists there's quite a few discussions on which order of arguments is the best. Usually the library's author use cases favor one order while some users prefer a different one. There's no golden rule, other than following the most usual patterns. For collections it's usual to place the container last (otherwise it ends different than List). What if I want to write:

insert k1 v1 $ insert k2 v2 $ insert k3 v3 map

The order for insert is the same used for filter, map & friends, with the container in the end. Searching on the mailing lists there’s quite a few discussions on which order of arguments is the best. Usually the library’s author use cases favor one order while some users prefer a different one. There’s no golden rule, other than following the most usual patterns. For collections it’s usual to place the container last (otherwise it ends different than List).

]]> By: Bryan O'Sullivan http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109105 Bryan O'Sullivan Wed, 26 Dec 2007 20:08:19 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109105 Using foldr to build a map gives you a gigantic space leak. Try it. If you're lucky, your compiler's strictness analyser might rescue you from the leak, but I wouldn't count on it. Regarding catMaybes, there's no real difference in the overall shape of the code. It just moves the case analysis to another place in the pipeline. Using foldr to build a map gives you a gigantic space leak. Try it. If you’re lucky, your compiler’s strictness analyser might rescue you from the leak, but I wouldn’t count on it.

Regarding catMaybes, there’s no real difference in the overall shape of the code. It just moves the case analysis to another place in the pipeline.

]]> By: sclv http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/comment-page-1/#comment-109104 sclv Wed, 26 Dec 2007 20:02:23 +0000 http://www.serpentine.com/blog/2007/12/26/design-your-functions-for-partial-application/#comment-109104 The problem is that lots of folks are going to want the value at the end. Say I want a map with something inserted, but I don't know what's inserted until later. Or say I want a foldr, which is a -> b -> b instead if a foldl' which is a -> b-> a ? Then the map as the first argument makes a great deal more sense. Anyway, looks like a job for a catMaybes in the pipeline rather than messing with the insert function at all, and as a bonus, you don't even need to write a helper function! The problem is that lots of folks are going to want the value at the end. Say I want a map with something inserted, but I don’t know what’s inserted until later. Or say I want a foldr, which is a -> b -> b instead if a foldl’ which is a -> b-> a ? Then the map as the first argument makes a great deal more sense. Anyway, looks like a job for a catMaybes in the pipeline rather than messing with the insert function at all, and as a bonus, you don’t even need to write a helper function!

]]>