CODEWITHSUNDEEP
haskellabstractionlambda
0xAX
0xAX

Reputation: 21817

Practice part of lambda abstractions

I'm new in Haskell programming. Now i'm learn lambda function and lambda abstractions. And i thought, what's the practice part of lambda functions. For example we have:

map(\x -> x * 2) [1,2,3,4,5]
[2,4,6,8,10]

What's of this practice part? We can create normal function and set it in map function argument. Only for code reduction? Then why was coming up this abstraction. Code reduction is not big point. Why?

Thank you.

Upvotes: 1

Views: 688

Answers (5)

sclv
sclv

Reputation: 38893

There's two ways to interpret this question. The first is why write map (\x -> x * x) when we can write

doubleIt x = x * x
... map doubleIt ...

The answer there is that you may have the following:

foo y zs = map (\x -> x^y) zs

and then there is no fully straightfoward transformation that allows you to float the anonymous function fully to the top level.

We could write

foo y zs = map (powerIt y) xs
powerIt y = ?

and then we discover that powerIt y = \x -> x^y ! (sure, you could float the x back to the outer definition, but in that case, you'd actually want to (although syntactically Haskell doesn't make you) write (powerIt y) as (\x -> powerIt y x).

When you have first class functions, they need to close over their environment, and that means that you need some way to introduce a function which can refer to things in the lexical scope where it is declared. That's the power of lambdas!

Now, the other question is why not float the anonymous functions to the appropriate level that's not the top and thus get, e.g.

foo y zs = let powerIt x = x^z
           in map powerIt zs

In that case, think carefully about what let really means again. In fact, we can transform the let into a few lambdas in the following way: foo ys zs = (\powerIt -> map powerIt zs) (\x -> x^y)

Now, in real implementations, these desugarings don't all happen exactly this way, and sometimes different clauses get treated differently by compilers for reasons involving efficiency. But the core thing remains -- lambdas are very powerful and expessive, and can give us a core language that is simple and easy to reason about despite the variety of binding forms that we layer on top of them.

Without lambdas we have a language where we can define variables and we can define functions and then we can sometimes do certain things with functions. With lambdas we have a language where functions are values just like any other value, and we have one set of uniform ways to assign names to anything.

The inversion of perspective is to see lambdas not as a special-case, but as the general case, and all our other various name binding mechanisms as sugar for them.

Upvotes: 4

Cedric
Cedric

Reputation: 720

If I understand your question correctly you are asking why someone would come up with the abstraction of Lambda functions outside of the scope of a specific programming language, correct?

Well, Lambda functions in programming languages are derived from Lambda calculus, which is a formal system for function definition. As Wikipedia says, Lambda calculus was introduced by Alonzo Church in the 1930s as part of an investigation into the foundations of mathematics. It has a wide range of applications, not just in Computer Science.

As noted by a commenter above, Functional programming has it's roots in Lambda calculus. I can only advise you to read the relevant entries in Wikipedia, there's some very interesting info in there ;-).

Upvotes: 0

David V.
David V.

Reputation: 5708

Readability; you can have ( far fetched, but to illustrate the point )

map (\x -> x * 2) . anotherfunction . anotheragain . itgoesonandon $
[ a lont list ]

vs

map f . anotherfunction . anotheragain . itgoesonandon $
[ a lont list ]
  where f x = x * 2

It's matter of taste but in the first case you know right away what function you are mapping, in the second one you have to locate f in the source code, and it might be a few lines away.

By the way, I would write map (*2) .... anyway

Another example is desugared monadic notation.

For example, 

do a <- action1
   b <- action2
   action3
   c <- action4 a b
   action5 c

becomes :

action1 >>= \a -> action2 >>= \b -> action3 >> action4 a b >>= \c -> action5 c

vs 

action1 >>= a2
  where a2 a = action2 >>= a3
           where a3 b = action3 >> action4 a b >>= a4
                   where a4 c = action5 c

(there might be an error in that code, but I would never write that anyways )

Upvotes: 2

frosch03
frosch03

Reputation: 729

you often face the situation, that you need a pretty specialized function. It is used in this part of your software and only there. Therefore it doesn't make any sense, to give it a concrete name.

Upvotes: 2

quanticle
quanticle

Reputation: 5020

Not all functions are used widely enough to "deserve" a name. For example, if you're only using this function once, for this specific map, you probably don't want to assign it a name because you'll never use it again.

Upvotes: 4

Related Questions