The Artima Developer Community
Sponsored Link

Weblogs Forum
Typing like a Functional Programmer

51 replies on 4 pages. Most recent reply: Dec 8, 2006 5:16 PM by Paul Berg

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 51 replies on 4 pages [ « | 1 2 3 4 | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:14 AM
Reply to this message Reply
Advertisement
> But, if I only give it one parameter, instead of failing,
> or giving a compiler error, it generates a new function
> that adds a constant (given as the single parameter) to
> its parameter.
>
>

> f = add(5);
> a = f(2);
> // a is now 7
>


Yes.

> So I assume this binding would be to the first parameter,
> so that:
>
>

> a = sub(7,2); // a is now 5
> f = sub(3);
> b = f(7); // b is now 4
>

>
> Have I got it?

Almost :-)

What you said is correct, but b will contain "-4". Do you see why?

Another way that I like to think about this is that the function f is a copy of the sub function, where the first parameter is always automatically 7.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 4:49 AM
Reply to this message Reply
> > function add_five = add_ints(5)
> > int x = add_five(3) // x == 8
>
> o.k., now I'm really confused. This function has STATE.
> It is an Object, not a Function. I thought the big
> g advantage of FP was no states, no threading issues, etc.
> I guess I'm missing something fundamental about FP.

Actually, it's a value and it's immutable. So there is no changing state. Changing state is the big concern in
FP.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 10:34 AM
Reply to this message Reply
> This function has STATE.
>
It has an immutable state, which is not what imperative programmers understand when they talk about state

> It is an Object, not a Function.
>
Many languages see functions as object, and every FP language does. In fact, lambda calculus (on which many FP are at least loosely based) is based on the axiom that functions are objects, and are the base building blocks of everything.

> I thought the big advantage of FP was no states
>
One of the advantaces of FP is the absence of state mutations. In this case, there is no state mutation.

> Bye the way, if I go
>
> add_ints(5);
> add_ints(6,7); (pardon me mashing the syntax)
> what gets returned? 18 or 13? And how do you know?
>
They're two completely unrelated calls.

add_ints(5) returns a function with an arity of 1 (it has a single argument) which perform the equivalent of "add_ints(5,x)" with x being the argument of the new function

add_ints(6,7) returns 13

Of course the C-like notation makes this extremely unwieldy, Haskell makes currying much cleaner and clearer:

Int

is the type definition of a single value
(Int -> Int)

This arrow notation is the type definition of a function. This function takes an Int parameter (before the arrow) and returns an Int (after the arrow). Type definitions are read from left to right by the way.

Now if we expand this to the addition, we get this:
Int -> Int -> Int

Takes an Int, then takes an other Int, and returns an Int.

If we add parens, we can get either:
(Int -> Int -> Int)

or
Int -> (Int -> Int)

Which mean exactly the same thing: "function which takes a parameter of type Int, then takes a parameter of type Int, then returns a value of type Int", which is equivalent to "function which takes a parameter of type Int, then returns a function which takes a parameter of type Int, then returns a value of type Int.

And if we check the code itself, the basic application would be
add 5 3

which can also be written
(add 5 3)

or
(add 5) 3

In the end, what "add 5" does is return an anonymous function of type (Int -> Int), to which we pass the parameter "3", whether we perform the second parameter passing explicitely or implicitely

> So I assume this binding would be to the first parameter,
> so that:
>
>

> a = sub(7,2); // a is now 5
> f = sub(3);
> b = f(7); // b is now 4
>

>
> Have I got it?

That's not exactly it, b would be -4.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 10:59 AM
Reply to this message Reply
Looks like Chris's blogs always attract lots of discussion :)
Anyway, this might be a bit off the topic, but I was wondering how does all this help in a bigger picture of developing large software systems. FP languages seem to have lots of nice little constructs (like Currying in this example), but do these things really help when writting industry-size software? I'm just curious if there are any real examples besides teaching. One of FP languages I really like is Scheme and I know people have done some serious things in it, but it seems to be only in academic areas.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 11:23 AM
Reply to this message Reply
> Looks like Chris's blogs always attract lots of discussion
> :)
> Anyway, this might be a bit off the topic, but I was
> wondering how does all this help in a bigger picture of
> developing large software systems. FP languages seem to
> have lots of nice little constructs (like Currying in this
> example), but do these things really help when writting
> industry-size software? I'm just curious if there are any
> real examples besides teaching. One of FP languages I
> really like is Scheme and I know people have done some
> serious things in it, but it seems to be only in academic
> areas.

I don't use functional languages for my work and am by no means an expert in them but what I have learned about them from reading and from using languages that support functional approaches (Scala, Python) has helped my greatly in my designs. I find more and more that I use functional approaches in Java designs, especially by simulating function passing with interfaces.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 1:07 PM
Reply to this message Reply
> I don't use functional languages for my work and am by no
> means an expert in them but what I have learned about them
> from reading and from using languages that support
> functional approaches (Scala, Python) has helped my
> greatly in my designs. I find more and more that I use
> functional approaches in Java designs, especially by
> simulating function passing with interfaces.

I agree. FP paradigm is useful with non-FP languages as well, but what I meant was using an FP language for a major project. There doesn't seem to be clear evidence that those are "better" than imperative ones.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 1:24 PM
Reply to this message Reply
Thanks for the clarifications on the state question. The immutability comments cleared most everything up.

So, in FP, if there are no mutable states, is it correct to say that you always (or nearly always) must have something on the left side of the = sign? (an lValue I believe it's called)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 1:52 PM
Reply to this message Reply
> > I don't use functional languages for my work and am by
> no
> > means an expert in them but what I have learned about
> them
> > from reading and from using languages that support
> > functional approaches (Scala, Python) has helped my
> > greatly in my designs. I find more and more that I use
> > functional approaches in Java designs, especially by
> > simulating function passing with interfaces.
>
> I agree. FP paradigm is useful with non-FP languages as
> well, but what I meant was using an FP language for a
> major project. There doesn't seem to be clear evidence
> that those are "better" than imperative ones.

Well, I've always thought that the 'no mutable state' thing is just ideological and/or philosophical. I mean, I will avoid have mutable states when I can to a point. The reality is that a lot of things have a mutable state and it's just easier (and I'd argue more correct) to model them in that way. The supposed dangers of mutable state are overblown. I rarely run into issues with it. Most of my bugs are process related.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:12 PM
Reply to this message Reply
> Thanks for the clarifications on the state question. The
> immutability comments cleared most everything up.
>
> So, in FP, if there are no mutable states, is it correct
> to say that you always (or nearly always) must have
> something on the left side of the = sign? (an lValue I
> believe it's called)

Bingo! And that is also the reason why naive implementations of funcional languages use so much memory. They create a gazillion copies of objects where a imperative language just reuses the same one.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:17 PM
Reply to this message Reply
> Bingo! And that is also the reason why naive
> implementations of funcional languages use so much memory.
> They create a gazillion copies of objects where a
> imperative language just reuses the same one.

There is a class of optimization called 'pruning' (I think) that can eliminate the unnecessary middle states at runtime. So this, from what I understand is not such a big problem.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:22 PM
Reply to this message Reply
>
> Well, I've always thought that the 'no mutable state'
> thing is just ideological and/or philosophical. I mean, I
> will avoid have mutable states when I can to a point. The
> reality is that a lot of things have a mutable state and
> it's just easier (and I'd argue more correct) to model
> them in that way. The supposed dangers of mutable state
> are overblown. I rarely run into issues with it. Most of
> my bugs are process related.

Accountants have learned the benefit of "no mutable state" long ago. You never change an existing entry; you make a new one that corrects the former mistakes.

It is safer to keep a history of changes than to simply overwrite them. The reason we don't keep them is because of space and speed. I am actually surprised databases have not caught up yet, well they sort of have with their transaction logs but the user has no easy access to those.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:36 PM
Reply to this message Reply
> > Bingo! And that is also the reason why naive
> > implementations of funcional languages use so much
> memory.
> > They create a gazillion copies of objects where a
> > imperative language just reuses the same one.
>
> There is a class of optimization called 'pruning' (I
> think) that can eliminate the unnecessary middle states at
> runtime. So this, from what I understand is not such a
> big problem.

Sure. If that was not so GHC Haskell would not be nearly as fast as it is, that is why I said "naive".

In other words: a naive implementation of C will be significantly faster than a naive implementation of "Haskell". Optimizing versions of the same will get closer in speed to each other over time. Alas, in either of the later ones you can probably take a nap while compiling long programs ;-).

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 2:58 PM
Reply to this message Reply
> > Thanks for the clarifications on the state question.
> The
> > immutability comments cleared most everything up.
> >
> > So, in FP, if there are no mutable states, is it
> correct
> > to say that you always (or nearly always) must have
> > something on the left side of the = sign? (an lValue I
> > believe it's called)
>
> Bingo! And that is also the reason why naive
> implementations of funcional languages use so much memory.
> They create a gazillion copies of objects where a
> imperative language just reuses the same one.

A naive implementation of any language will always be naive, and will have problems with memory consumption, incorrect behaviour, and efficiency.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 3:14 PM
Reply to this message Reply
> I agree. FP paradigm is useful with non-FP languages as
> well, but what I meant was using an FP language for a
> major project. There doesn't seem to be clear evidence
> that those are "better" than imperative ones.

That would be a subjective claim and impossible to verify. There is never going to be an answer to the question of which approach is "better".

I believe it behooves a programmer to learn both approaches to be able to make better educated design decisions. Some problems just seem to be better suited to one approach or another.

To answer your original question one well known industrial-strength example of successful Functional programming use is at Google ( http://labs.google.com/papers/mapreduce.html ). Functional programming approaches are also very popular in parsers, compilers and interpreters.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Typing like a Functional Programmer Posted: Nov 28, 2006 3:20 PM
Reply to this message Reply
> Thanks for the clarifications on the state question. The
> immutability comments cleared most everything up.
>
> So, in FP, if there are no mutable states, is it correct
> to say that you always (or nearly always) must have
> something on the left side of the = sign? (an lValue I
> believe it's called)

In virtually every language you always need something on the left of the = sign, and yes it is called an lvalue. What langauges do you not have them? Is this indeed what you meant to ask? Perhaps you meant to ask whether a new variable must always be used as an lvalue? The answer would be yes for a "pure" functional language. The caveat is that many functional languages (e.g. Scala, OCaml, Lisp) do in fact allow mutable variables but are often referred to as impure functional languages.

Flat View: This topic has 51 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Typing like a Functional Programmer Previous Topic   Next Topic Topic: My Own Personal Blog


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us