---
@pron
Nowadays I prefer the terms “effect-free” and “effectful”, rather than “pure” and “impure”, since I don't want to suggest that effects are somehow “wrong” or “evil”. By definition, values are effect-free. An effect is anything that invalidates some equational law that holds for values.
For example, integer equality is decidable, and `x == x` evaluates to `true` when `x` is any integer value. However, if we substitute `x` with the expression `foo()`, where:
int counter = 0; // or any other initial value
int foo() { return counter++; }
Of course, nontermination is an effect too. If we had defined `foo` as:
int foo() { while(true); return 0; }
---
> An effect is anything that invalidates some equational law that holds for values.
Ah, I can certainly accept that as a definition, except that I'm not sure how different it is from mine, because the equational law you refer to applies to syntactic terms (`foo` in your example) and the language's equality operator (`==` in your example). It's easy to come with an equivalence relation that would hold for `foo`, but not at the syntax level (e.g., equality that takes `foo` to mean `foo`'s definition and the content of the heap, and the value of `foo` would not be its return value but its behavior -- i.e., the behavior of foo for equal heap contents is always the same).
An effectful language can be given a denotational semantics. At least from what I've seen, when most people say “pure”, they mean “effect-free”.
> It's easy to come with an equivalence relation that would hold for `foo`, but not at the syntax level [emphasis mine]
Yep, indeed, that's the whole point.
But saying "effect free" doesn't mean much unless you define what an effect is, and what constitutes an effect depends on the language. I meant to define the same thing without referring to another vague definition.
Not the runtime equality testing operator. Rather, the language's static notion of contextual equivalence.
It just happens to be the case that most high-level languages provide a built-in equality testing operator that works on primitive types, returning `true` iff its operands are contextually equivalent values.
> I think assembly language and BASIC would still qualify as effect-free
I don't even know what a good notion of contextual equivalence for any assembly language would be.
As for BASIC, I haven't used the old ones, so I can't comment on them. I've used Visual Basic, which most certainly has effectful procedures.
How is that different from denotational semantics?
> The ones that can be effectful or effect-free are specific computations, not whole languages.
Well, we could define an effect-free language as one where all programs are effect-free. But anyway, what is the "static notion of contextual equivalence" in assembly (or BASIC), and how can you write an effectful program in such a language?
Pure is not quite the opposite of imperative; declarative is the opposite of imperative, although in practice it is true that pure functional languages tend to be more declarative that imperative functional ones.
You can have pure (AKA referentially transparent) imperative languages if they are synchronous[1]. The synchronous style is especially well suited to reactive/interactive applications, and quite popular in hard realtime applications.
Also, we don't really have exact definitions to any of these terms (imperative, pure, functional, declarative). Here is my attempt for approximate, problematic definitions:
* Functional -- a language that models most/all computations as (possibly partial) mathematical functions, and constructs a program by assembling those functions.
* Imperative -- a language that models computation as state transitions, specifying what state should the computation have at each step.
* Declarative -- a language that describes what result should the program give (as a function, a relation or a behavior) rather than at each step.
* Pure -- a language where the semantic value of the composition of syntactic terms can be determined by the semantic value of each of the component terms and no others.
[1]: https://en.wikipedia.org/wiki/Synchronous_programming_langua...