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
| [reply] |
| [reply] |
Doesn't Haskell play in the purely functional league too?
Haskell is the example usually given, but I am told
that Haskell has something called monads (don't ask me
what they are; I don't have any idea) which allow state
to be stored external to the function. Perhaps someone
who knows more about Haskell could comment on this. I
personally don't think that really keeps it from being
a pure functional language, but to explain why I have
to step aside and talk about another language...
The other usual example is Lisp (or a variant, such as
Scheme), but I really don't consider Lisp and its kin
to be functional per se, though they have
stuff in common with functional languages, and if you
start throwing around lambda expressions your program
can be very functional. But I would say that functions
in lisp are just a special kind of list; any given
list may or may not be valid as a function, but
every function is a list. Lisp is fundamentally
list-oriented, then, and functions are just one
important kind of list. This makes it possible to
program in lisp according to a functional
paradigm, but it is also possible to not do that --
for example, to use a procedural paradigm, if one
chooses. I have done so in a number of cases.
(Just one example: most .emacs files are very
procedural in nature.)
In that respect, lisp is like Perl: it is a
general-purpose language, not tied to one way of
doing things.
Haskell, OTOH, is very much tied to one paradigm, so
it could be argued that it is purely functional
indeed, because even if these monad thingies give it
the ability to store state external to a function, it
still is approaching the issue from a functional
perspective at some level. I have not seen anyone
claim to have used a procedural or object-oriented
paradigm when writing in Haskell. If state is stored,
it is stored for the benefit of functions, which
are the main focus. In lisp (or Perl), I can write a
program that consists entirely of one big main routine
which does not return any significant value at all.
Sure, it calls some builtin functions, but that's
also true in C, BASIC, and even assembly language,
and nobody is going to call those functional.
So I think when we decide whether a language is a
pure functional language, that may be the question to
consider: does it allow for completely abandoning the
functional paradigm and writing code entirely another
way (e.g., procedural or OO). If it does, the language
may have functional bits, but it is not functional
per se.
OTOH, if we apply the analogous criterion to OO, I do
not think I know of a single pure object-oriented
language. All the OO languages I know about, it is
possible to write procedural code if you want.
Unless you count data description languages (such as
POV or XML), but that's different.
sub H{$_=shift;while($_){$c=0;while(s/^2//){$c++;}s/^4//;$
v.=(' ','|','_',"\n",'\\','/')[$c]}$v}sub A{$_=shift;while
($_){$d=hex chop;for(1..4){$pl.=($d%2)?4:2;$d>>=1}}$pl}$H=
"16f6da116f6db14b4b0906c4f324";print H(A($H)) # -- jonadab
| [reply]
[d/l] |
Yes it does. I looked at that one too. I did not like the monad style IO there though. I find the unique types of Clean easier to understand ... and more natural within a purely functional code.
The plus of Haskell compared to Clean is that it's open source and that there are more implementations and probably more libraries (it's some time since I played in these parts :(
Clean seems to be pretty silent :-(
Jenda
| [reply] |
