Lambda the Ultimate

Depending of the implementation it can be a very good contender to Haskell for pure FP

Both Clojure and Erlang are impure functional languages. That's not a complaint or a slam. I like both - and I happen to use several other impure functional languages (Scheme and Scala). It's just that if the word "pure" is to mean anything at all, then languages like these don't fit.

To really understand what people mean by purity in a functional language, see What is a Purely Functional Language.

The main point the paper makes is that in a purely functional language call-by-name, call-by-need (lazy), and call-by-value (strict) evaluation strategies are all equivalent modulo non-termination issues.

Both languages are impure for the way they deal with IO, among other things. If you have a function called "read-string" which gets a string from the user at the console then the equivalent of the following will have different results depending on evaluation strategy (here I use Clojure syntax, but same idea in other syntaxes).

(let [a (read-string)]
     [b (read-string)]
  (foo a b))

In call-by-need and call-by-name it's hard to say how often read-string will be called, and what variables will hold which input at which time. That's why Clojure and Erlang and, indeed, most impure languages use call-by-value.

I should have used the term "single assigment languages". Is there any way that a dynamic language with I/O can be made "pure" as you defined? The only ways to restrict I/O that I know involve static typing (monads or effect types).

The encoding underlying monads for IO is just continuation passing style, which you could do in a dynamic language.

A simple (re-)definition (or consequence) of pure is that all side-effects carrying code is made explicit by the type of the code. A language is either pure or impure, it cannot be both.

The question wasn't whether a language could be both pure and impure (which means "not pure", right?), but whether it could be pure and dynamic. Purity (as I believe it is commonly understood) doesn't have to do with the type system, but whether side effects occur during evaluation.

Sorry, got the question wrong. Then, yes a dynamic language can be pure. Seems to be an orthogonal feature.

Hmpf, with regarding to purity. Well, the redefinition is not entirely correct ;-), granted, but, given current understanding of 'purity', it is as good as any. But it is actually cumbersome to talk about purity. Even in, say, Haskell, where every program is pure, it's evaluation might not be; it really is a semantical mess.

Thought about it a bit more. Also, given inspiration by the pure functions post.

I guess the best way to state is that you don't have "pure" programming languages, but only "pure" functions (those functions which are confluent under normal beta-reduction). Now, Haskell is pure, in the sense that all functions you write are all confluent (modulo termination), but the programs written which use the IO monad when evaluated are not.

The question is "can a pure dynamic language exist", should be read as "can we write pure dynamic functions?"

I think so, but you need a bit of a different semantics for your language where function symbols are not constants, but refer to names which are all bound in the current scope of a function. That way you can change a function (definition), pass the scope to all next calling functions, and all remains "pure".

Reading "pure language" as "language in which we can write pure functions" will put you on a different page from anyone else using the term. Haskell's rules for interpreting IO are in a completely different semantic domain from its functions, all of which (modulo unsafe*) are pure.

Well, a pure language would be a language in which (it seems?) you can _only_ write down pure functions.

God, "Haskell's rules for interpreting IO are in a completely different semantic domain from its functions" doesn't make it any better does it? Okay, say Haskell can do impure stuff, but from a entirely different semantic domain. Is that then not part of the Haskell semantic domain?

(Disclaimer, I really don't care to much about it. Maybe drop it?)

cf list discussions and some actual testing which might help folks figure out what the real deal is with contention.

some cold water on stm in there.