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 ]
Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Typing like a Functional Programmer Posted: Nov 30, 2006 2:44 AM
Reply to this message Reply
Advertisement
> > > > > - generic programming
> > > > Rather than repeat the same comment, I'll ask what
> > > makes
> > > > you think that FP does not support generic
> > programming?
> > >
> > > It does through dynamic typing (probably depends on
> the
> > > language)
> >
> > Probably depends what you mean by generic programming.
> >
>
> I was thinking in more specific terms, for example, the
> following C++ function is generic:
>
> template<class T> bool equals(T x, T y) { return x == y;
> }
>
Generic programming is very common in functional languages
like Haskell or ML. In fact generic programming has its roots in FP: Its foundations are System F (Girard/Reynolds 72-74) and the Hindley/Milner system (75), the first well-known language to have adopted it is ML (also around 75). Only 10 years later was generic programming transplanted to imperative languages. One of the first to do so was Eiffel.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Typing like a Functional Programmer Posted: Nov 30, 2006 3:34 AM
Reply to this message Reply
Alex Stojan wrote
> I was thinking in more specific terms, for example, the
> following C++ function is generic:
>
> template<class T> bool equals(T x, T y) { return x == y;
> }
-snip-
> I don't know other FP languages, so I'm not sure if they
> support generic programming more directly.

In Clean http://clean.cs.ru.nl/

equals x y = x == y

(equals 5 5) &&
(equals 'a' 'a') &&
(equals "abc" "abc") &&
(equals 5.0 5.0)


The types inferred by the compiler were

equals :: a a -> Bool | == a

equals :: !Real !Real -> Bool
equals :: !{#Char} !{#Char} -> Bool
equals :: !Char !Char -> Bool
equals :: !Int !Int -> Bool


Compilation will fail if == is not defined for a

:: X = MakeX Int
(equals (MakeX 5) (MakeX 5))

Overloading error: "==" no instance available of type X

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Typing like a Functional Programmer Posted: Nov 30, 2006 10:06 AM
Reply to this message Reply
> Generic programming is very common in functional
> languages
> like Haskell or ML. In fact generic programming has its
> roots in FP: Its foundations are System F (Girard/Reynolds
> 72-74) and the Hindley/Milner system (75), the first
> well-known language to have adopted it is ML (also around
> 75). Only 10 years later was generic programming
> transplanted to imperative languages. One of the first to
> do so was Eiffel.

Thanks for the info! I assume from these examples that generic programming requires compile-time checks, so the Scheme version probably would not qualify as generic.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Typing like a Functional Programmer Posted: Nov 30, 2006 1:08 PM
Reply to this message Reply
> I don't know other FP languages, so I'm not sure if they
> support generic programming more directly.

Actually, ML was partly an inspiration for C++ templates: http://www.research.att.com/~bs/bs_faq.html#advanced

Chris Rathman

Posts: 2
Nickname: critter
Registered: Jul, 2003

Versions for Python, Ruby and JavaScript Posted: Dec 1, 2006 6:29 PM
Reply to this message Reply
Since I've been translating parts of SICP into a number of languages, currying is fresh on my mind. Perhaps versions in some of the popular scripting languages will help others make a connection.

Here's a Python version:

def add_ints(x):
return lambda y: x + y
add_five = add_ints(5)
print add_ints(5)(3)
print add_five(3)


Here's a Ruby version:

def add_ints(x)
return lambda{|y| x + y}
end
add_five = add_ints(5)
puts add_ints(5).call(3)
puts add_five.call(3)


And if all else fails, here's a JavaScript version:

function add_ints(x)
{
return function(y) { return x + y; }
}
add_five = add_ints(5);
document.writeln(add_ints(5)(3));
document.writeln(add_five(3));

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Typing like a Functional Programmer Posted: Dec 5, 2006 10:03 AM
Reply to this message Reply
add = \x -> (\y -> x + y)
add x y = x + y
add x = \y -> x + y
add x = (+ x)
add = (+)

Paul Berg

Posts: 3
Nickname: procyon
Registered: Dec, 2006

Re: Typing like a Functional Programmer Posted: Dec 8, 2006 5:16 PM
Reply to this message Reply
> - all OOP related techniques and principles
Depends on the functional language.

in Common List, CLOS is the defacto OOP library which is a very powerful library.

In Scheme, a common joke is that Scheme programmers know quite a bit about OOP... they have generally implemented it from scratch at least twice and use the version tailored for the problem at hand. Good multi-inheritance OOP models can be implemented in a few lines of code. Most of the time you don't need OOP as closures are more flexible.

OCaml is so OOP it has Object as the first word in it's name.

Haskell is above OOP... type classes are FAR more flexible that asking a Haskell programmer to use traditional OOP is like asking a C++ programmer to stop using inheritance.


> - generic programming

Lots of Generic programming in functional langs. The Lisps typically don't use them because they have dynamic typing, but I know Haskell has a large generic library.

> - using constructors/destructors to allocate and
> deallocate resources (RAII)

Garbage collection handles alot of this. Most functional languages also have an anagolous mechanism

> - using exemplars or prototype objects to serve as basis
> for new objects

Closures. They do all this and more.

> - using function objects

Function objects are a hack to make imperative languages do functional programming things. Having first class objects make "function objects" just silly.

> - defining copy-constructors

These are only needed in imperative languages. The hybrids, like Lisp have similar things. The pure functionals do not need them. Think about it.... if by definition NOTHING is ever mutable, why would you ever need to copy anything. Simply take as many references to the object as you like as you are guaranteed that the object will never change.

So, to answer your question rather than each of your examples, the hybrids (Lisp, Scheme, OCaml, etc..) tend to use techniques from both worlds. The pure languages either don't need the technique that the imperative world uses because the problem the imperative technique is trying to solve is a trivial one, or they use an equivelent technique, or in some cases, the technique that the imperative language uses is impractical in functional paradigms and so they use a completely different and novel technique. Also, just like there are some problems in imperative programming that are so absolutely trivial from a functional perspective (non-synchronized parallel threading for instance) that they aren't even problems, the converse is also true. For instance, in a purely functional language, everything can be done out of order and no side effects are allowed. Writing to a port is a side effect. now imagine this code snippit in a functional language:

print("hello world");
print("hello again");

Not only can you not print, but even if you could, you can't print IN THE RIGHT ORDER. This is a (nominally) hard problem in functional programming (solved by monads BTW).

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