to avoid naming intermediate variables

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

to avoid naming intermediate variables

Dennis Raddle
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



_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: to avoid naming intermediate variables

Michael Orlitzky
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))

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: to avoid naming intermediate variables

Dennis Raddle
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


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners