Re: Re: (tye)Re: Why Closures?

[Jenda]

IMHO it's better to use the positive definition "FP allows you to treat functions as data" than the negative one "FP is without side effects".

If you insisted on the negative definition then even most officialy functional languages would not be functional. And if the FP was only about the restriction it would not be very attractive ;-)

For me FP means two things. Higher order functions+closures (which is something we have in Perl) and a good general type system with real polymorphism (map: (( 'a -> 'b ), 'a list) -> 'b list) (which is something that we don't have in Perl, but since we have no types I don't feel restricted).

Jenda

P.S.: It's a shame Microsloth did not steal either from FP for it's .Net :-(
C# still feels like something 30 years old :-(

[jdporter]

IMHO it's better to use the positive definition "FP allows you to treat functions as data" than the negative one "FP is without side effects".

Suit yourself. You'll find yourself in the minority opinion wrt computer scientists.

If you insisted on the negative definition then even most officialy functional languages would not be functional.

Not true, there are some "pure" FP languages. Of course, like most single-paradigm languages, people don't use them very much!

[Jenda]

If you read once more what did I say you'll find out that I DID NOT say there are no pure FP languages. I've spent some time with one (Concurrent Clean) and I DID like it!

I am not using it now though, noone around here would be able to cooperate with me :-(

The reason why did I like Clean was not because it restricted me (no side-effects), but because of the restriction it was able to offer something (laziness). Of course the generality of the type system and ability to compose functions at will was appreciated as well.

Jenda

[Aristotle]

Doesn't Haskell play in the purely functional league too?

Makeshifts last the longest.