Public ScratchpadDownload, Select Code To D/L
OT: Alterative Programming (or maybe "Federal Programming") To preface, this is an idea I had (in a very early stage). It's the beginning of an answer to a question that has eaten at me since grad school. It's entirely possible that someone other than me has had this idea, already, and I just haven't heard about it... so please be forgiving (but let me know!) if this is the case. It's also entirely possible that the inevitable conclusions of this line of reasoning lead to a dead end... I'm kind of thinking out loud, here. Anyway I'll just start with the punchline, and then get into the motivation and details, later.

Punchline

The idea is to essentially resolve what I consider to be "The Problem" with functional programming... as can be described by the following (mutually contradictive) observations that were apparent to me from my first introduction to functional programming:

The short story for how to resolve this issue, generally, is to consider all the state (all the state in the whole world in which a program might be interested) as part of the input to a program, and some new (again global) state to be part of the output (translate "input" and "output" as "parameters" and "return value" if you want to be strictly functional in your terminology). Basically, I think this idea destroys many of the virtues of functional programming... basically that it introduces a completely artificial temporality to functional programming, thus killing the idea that expressions are intrinsicly parallel and that they have no side effect (which is really the whole damn point). In short, this is why lisp has "print". Yuck.

My idea, however, is to maintain the notion of truly side-effect-free functions (programs, subprograms, whatever). These functions, however, do have the ability to inspect the global state, but not to alter it. Instead, a function can return an alteration to state. Or, perhaps better put, a description of an alteration to state. These descriptions of alteration to state (maybe I'll call them "state-diffs" for now), could be interpretted as a request for said alteration to be resolved into and committed to the global state (i.e. "patching" the "state-diff"), but that certainly wouldn't be the only possible use.

Okay... But Who Cares?

The short answer is: there's just something that feels right about this idea (to me, at least). Quite frankly, it presents a very clean looking mathematical model for many things you'd like to be able to do with programs. Of course, that doesn't mean much for someone using a programming language.

A more practical answer, however, is that there are a great deal of practical benefits of this model. More to the point, there are a great deal of practical benefits of truly side-effect-free code. I mean really side-effect-free. For example: implicit parallelization, no action-at-a-distance bugs, implicit transactions

see RFC: Implicit Parallelization Pragma