I recently realized one important reason Haskell is so compact---it provides structures that avoid the need to name intermediate variables. I guess it's obvious, but coming from an imperative background I didn't see this at first. I am starting to recognize situations where all the existing wonderful typeclasses assist in eliminating variables. Function composition is the simplest example. I sometimes write long chains of composed functions. In an imperative language with a less compact function call syntax, that would require so many parentheses that you would probably break it over several statements, then forcing you to use more variables. Then I realized that Arrows allow a little more flexibility when you have different numbers of arguments to feed, say when you split a single argument into two, or want to construct a function that applies to one argument and ignores the other. ...So I had to write something like this. compute :: [Int] -> [Int] -> [Int] -> [(Int,Int)] func :: [Int] -> [(Int,Int)] func xs = compute xs (filter isSmall xs) (filter isLarge xs) but I could also write compute :: ([Int],([Int],[Int])) -> [(Int,Int)] func = compute . (id &&& filter isSmall &&& filter isLarge) So I had to change the inputs to 'compute' into this kind of awkward tuple form, but I eliminated four 'xs', plus eliminated the need to come up with the name 'xs'. Can I get a comment on whether this makes sense as way to do things? D
On 02/22/2016 03:40 AM, Dennis Raddle wrote:
...So I had to write something like this.
compute :: [Int] -> [Int] -> [Int] -> [(Int,Int)]
func :: [Int] -> [(Int,Int)] func xs = compute xs (filter isSmall xs) (filter isLarge xs)
but I could also write
compute :: ([Int],([Int],[Int])) -> [(Int,Int)]
func = compute . (id &&& filter isSmall &&& filter isLarge)
So I had to change the inputs to 'compute' into this kind of awkward tuple form, but I eliminated four 'xs', plus eliminated the need to come up with the name 'xs'.
Can I get a comment on whether this makes sense as way to do things?
It's pushing it. Once you've seen the trick with (&&&) it's tempting to use it. When I see (id &&& f &&& g), in my head I get a picture of some argument coming in and being split along three wires that get fed into id, f, and g simultaneously. The output from those three black-boxes then get fed into compute: ----f---- / \ compute <------g------<-- xs \ / ----id--- So while details with the nested tuple are ugly, what will happen is pretty clear to me. But how long did you have to play with the arrow combinators to make this work? If you-two-weeks-ago were to see that line, compute :: ([Int],([Int],[Int])) -> [(Int,Int)] func = compute . (id &&& filter isSmall &&& filter isLarge) how long would it have taken you to figure out what it did? How does it impact your documentation for the "compute" function? I imagine it was something like "takes a list of Ints, the small half of that list, and the large half of that list, and then computes something cool." Now it will be "takes a pair whose first component is a list of Ints, and the second component is a pair whose first component is a list of the small half of the list in the first component of the big pair, and..." It's hard to explain because it's weird to think about. In this case, the second and third arguments to compute can be... computed... from the first, so in practice I would do something like, compute_stuff :: [Int] -> [(Int,Int)] compute_stuff xs = compute xs small_xs big_xs where small_xs = filter isSmall xs big_xs = filter isLarge xs compute :: [Int] -> [Int] -> [Int] -> [(Int,Int)] compute = -- whatever it's supposed to do (Unrelated: it might make more sense to loop through "xs" once and return a pair of the small/large elements. That way you don't have to make two passes. Depends on the size of the list.) If you're just code golfing, you don't need to change the signature of the compute function. Hitting it with "uncurry" once makes it take a tuple, and hitting it with (uncurry . uncurry) makes it take a tuple whose first component is a tuple: -- oh god what have i done func :: [Int] -> [(Int, Int)] func = ((uncurry . uncurry) compute . ((id &&& filter isSmall) &&& filter isLarge))
Yeah, maybe I've been a little too enthusiastic about code golfing. I've noticed that haskell programs usually have short functions (compared to imperative languages). I love this---I love how when you get a function down to four or fewer lines, you can tell its structure in a glance. Yes, some Haskell structures can look confusing at first, but I find that with practice looking at them, they start to look natural. Like the way that your mind pictures &&& splitting the input---I'm sure you find that doesn't take any effort and feels like a common and natural pattern. It seems to work like that with much of Haskell. Oh, can I bring up one other intermediate variable elimination situation? I used to do things like func :: IO MyData func = do x <- readMyData return $ someProcessing x When I first encountered Monads, I was confused by functions that move things into Monads, like 'liftM'. But I am starting to see the light. I realized I could do func = someProcessing `liftM` readMyData Or func = readMyData >>= someProcessing I was explaining to a friend that Haskell's abstracted patterns seem confusing to me, coming from an imperative background. She only has a little experience programming, so I tried giving some analogies. Say you are an imperative programmer and you are do a physical simulation of automobiles. You see that they all have an engine, so you write some code that handles abstracted common features of engines. In Haskell, abstracted patterns are more like this--say you have a a forklift that manipulates boxes. say that's your "function." Then you write a function that produces a forklift that manipulates boxes that are inside trucks. In the imperative world, it's like "huh? where does that get you?" But it makes more sense now. D
participants (2)
-
Dennis Raddle -
Michael Orlitzky