Lambda the Ultimate

Referentially transparent code is, by definition, not really doing anything; it's an inert definition, determining the actual value of which is an implementation detail.

I suspect you confuse purity (mathematical function mapping local inputs to local outputs) with referential transparency (semantics of expression independent of referential context).

You can have impure RT code that 'does something' or 'observes something' - and this isn't so unusual in various logic programming, concurrent constraint programming, declarative concurrency, and some reactive programming models. In these cases, removal of the expression can affect the behavior of the whole system, even if there is no observable 'value' associated with the particular expression.

You can also have pure code that isn't RT, as when using dynamic scoping for pure variables.

I suspect you confuse purity (mathematical function mapping local inputs to local outputs) with referential transparency (semantics of expression independent of referential context).

Hm, my working definition is "referential transparency" meaning something like "expressions are indistinguishable from the value they reduce to". If a function application is indistinguishable from what it evaluates to, that's a pretty strong constraint on being able to "do" anything.

If I'm incorrect, I'd appreciate a reference to a proper definition. I fully admit that I've picked up a lot of these ideas in an informal, ad-hoc manner, and may be confused...

A few papers: [1] [2]

RT has a really muddy meaning, going back to when Quine originally defined it for natural language in 1960. Strachey applied it to programming languages in 1967. RT is is about whether a given expression (reference, symbol) will have the same semantics (referent, effect) in a 'slightly' different context - such as after moving the symbol relative to another, or copying the expression. There is no absolute definition for RT because there is no clear definition for 'same referent', nor an absolute definition for 'slightly different context'.

Rather, you might measure RT in degrees, in terms of which transforms you can perform without destroying reference relationships of expressions. Can you move the expression in space (commute it within a larger expression? code distribution? location transparency?) Can you move it in time (as for laziness and concurrency)? Can you replicate the expression without changing its semantics? Can you lift a duplicate to a single call in a 'let' expression?

The "expressions indistinguishable from the values to which they reduce" definition is pretty much purity with no hidden parameters, or purity + RT. It can be weakened greatly and still retain useful properties:

If you allow dynamic scoping and hidden arguments, and monadic syntactic sugar, you can still have 'purity' in the sense of no effects other than a mapping from inputs to outputs. You can replace the expression with the value to which it reduces. However, because of the hidden inputs, you cannot move or commute the expression with the same freedom as you may move or commute the resulting value. You can distinguish the expression from the resulting value by placing each into various alternative contexts, and noting that the expression's value varies based upon hidden inputs, whereas the normal-form value does not change. Thus, purity does not imply RT. The advantages of purity remain, though, such as support for laziness, partial-evaluation, parallelism, determinism.

Similarly, you can allow effects other than reduction to a value, support hidden outputs and hidden inputs, and still maintain RT. This is made clear when working with various designs for declarative concurrency, including use of future values and promises (as in Oz or Alice), concurrent constraint programming, and even reactive programming where one can 'reduce expressions to behaviors' rather than to values. In many of these cases, despite having hidden outputs and inputs, one is entirely free to commute expressions, to replicate them in space or eliminate replicas (repeating a constraint has no additional effect), even to move them in time by introducing concurrency (even to the extent of making every expression concurrent). All the relevant aspects of RT are maintained, despite the fact that one cannot reduce the expression to a value.

Imperative expressions are neither pure (cannot be reduced to a value) nor RT (cannot be moved or replicated in space or time). They are all tied together by weaving the hidden outputs of one expression (time, state) as hidden inputs to another. Declarative expressions can do the same, as when weaving monadically, but generally do so to a lesser degree and offer greater control. If you compare pure RT functional code only against imperative effects, you're trapping yourself with a false dichotomy and you're missing out on many rich classes of effects that lie between.

Pure functional languages generally focus more on expressing what a program does rather than the how it is going to do it. How is an implementation detail that you leave to the compiler which handles the messy part of mapping what you want to do onto the stateful machine that is going to execute it.

Your debug information isn't really part of what the program does, it is really concerned with how it is done so there is a bit of a mismatch. I think it would be very awkward to do what you asked in a pure functional language.

I disagree. Only the goal-based disciplines that leave search up to the runtime (such as constraint programming, logic programming, certain uses of modeling languages) can really be said to focus on 'what rather than how'.

Rather, functional programs express a particular strategy or algorithm for performing a calculation. The same darn function can be expressed many different ways, and functional programming forces you to pick one of them: the How, rather than the What.

For a pure language the compiler has considerably more freedom to reorder this algorithm, perform partial-evaluation, lift expressions to avoid a multiple-evaluation, etc. than it would for an imperative expression of the same program (especially in presence of modularity). Similarly, the programmer has a great deal more freedom to do the same, and to introduce arbitrary abstractions, without fear of changing program semantics. These are not inconsiderable advantages.

But, despite being relatively declarative, expressions within a functional programming language are still quite mechanical.

Even constraint and logic programming usually have a computation model in mind. If you really want to focus on the 'what' rather than the 'how', you produce a specification as a proposition to satisfied by a solution, and leave the implementation with an intractable search problem.

Constraint programming can do that for you very easily. Constraint satisfaction problems are among the easiest to express, and at least a few constraint programming implementations support structured data well enough that one could express constraint satisfaction problems that request source-code inputs (or at least ASTs) that will meet certain invariant properties under a given evaluation function. :-)

And you are correct that "logic programming" as commonly implemented (horn clauses and such) would not be able to do so. I was thinking of the more general paradigm: logic programs are reversible. One can provide the output and ask to browse the inputs that lead to it. This can also give you a nice, intractable search problem, and can also be used to produce source code as the input to produce outputs meeting certain invariants.

The application of using such (in-the-large intractable) searches to produce code from a specification has been called 'declarative metaprogramming' in the literature. One can also apply these during runtime, balancing the nigh-intractable nature of the searches against the specialization advantages that come from extra information available at runtime.

The comment system seems to have messed up, that was actually a reply to an earlier comment so it isn't clear if you realized that or not.

Functional languages, relative to imperative languages, generally have a much more narrow focus on defining what the result of the computation will be while specifying fewer details (how parameters are passed, how memory is managed etc.) that commonly need to be handled in lots of imperative languages. By "what" I mean the core computation that is the raison d'être of the program and by "how" I mean all the details about how the core computation is mapped onto the machine (or machines) that are going to execute it.

The distinction you make between what and how seems to be of little practical interest.

Programming at higher abstraction is achieved by use of abstraction primitives (such as variables, functions, macros, dynamic scope, implicit typing, templates/generics) and domain-specific libraries.

Level of abstraction (distance between developer and hardware) seems much closer to what you mean with regards to describing computations with few low-level details. It is perfectly feasible to program imperative languages in a very high level - if your abstraction facilities are adequate to the task (and don't leave you fretting about performance).

I'm certain you could point to several imperative languages whose abstraction facilities are inadequate, but anyone else could point in turn to Forth and Lisp.

Where the imperative model fails me has much more to do with problems of the model itself: poor handling of domain concurrency, poor local reasoning about or recovery from partial failures, reduced flexibility for abstractions (since you must often maintain order of expressions), reasoning about anything at all in the face of modularity, performance in distributed systems vs. complexities of explicit caching, inefficient expression for reactive flows (operating based on changing state of environment), poor support for separation of concerns: 'thinking' from 'acting' (or calculation from IO), and so on.

Of course, variations on the model fix some problems. For example, object capability model (memory safety + eradicate global mutable state) greatly simplifies reasoning about programs in the face of modularity. And process calculi of various sorts can help reason about concurrency.

Who hurt you, Johnny? Was it a functional programmer?

Zarko could be a sockpuppet for Erik Meijer... ;)

Never had a chance to meet Erik, maybe when he snaps out of the VB phase (VB being one of few languages I'll never touch).

In case you guys haven't noticed the subject asks for criticism and criticism is not an easy reading for a devotee.

If the guy who asked for it actually has some use for such info (like that he's starting or thinking about a project) then spelling out what you don't like may help him. Don't take it personally - imagine if GM was asking, and listening, what people didn't like about their cars ...

I was only kidding. And of course, you make some good points, particularly regarding the availability of industrial-strength tools and focus on debuggers and other peripheral programming support.