Lambda the Ultimate

Yes, the diagram is a slightly revised version of the one discussed before. As far as I understand, the diagram was made for a talk at a Symposium at IRCAM in 2007, and this paper/chapter is part of a forthcoming book "New Computational Paradigms for Computer Music".

BTW: I reformatted the announcement to match the common format of front page stories of this kind.

Good stuff.

Done.

regardless of the presence of state--what is visible via an API is frequently a subset of what is visible via use of introspection or with a debugger.

Sometimes, named state is necessary to support a stateful abstraction--a BankAccount object by design will hold different values for its AccountBalance attribute (however derived) at different times. Other times, named state may support a stateless abstraction, for example, with explicitly encoded memoization in a language without a delay primitive or default lazy evaluation.

One other notion regarding state that might merit some expansion. In the Big Chart, which has been expanded quite a bit since its last appearance on LtU; there is noted the difference between "cell" and "local cell"; the latter being defined in the context of concurrent languages which permit thread-local storage, essentially, but for which state is not visible across process boundaries. "State" without the local qualifier refers to either mutable cells in sequential languages, or to shared state in concurrent languages such as Java. I think this is a useful dichotomy to make, but one which merits further consideration.

Furthering the confusion--most of the exampes cited for "local cell" are languages or systems which eschew shared state due to the well-known reliability and scalability problems with monitor-based synchronization, even when the system in question has multiple threads running on the same processor. Yet the final example is tuple spaces a la Linda--the purpose of which is to simulate monitor-based shared memory on a distributed system. It's not a full simulation, obviously--since individual transactions with the tuple space are atomic, but explicit locking of the tuple space is not available, tuple spaces don't suffer from deadlock; but the inclusion of a means to simulate shared memory on hardware that doesn't support it easily seems to violate the spirit of the "local cell", even though tuple spaces operate on top of message-passing in the distributed system case. (Of course, the same is true for RDBMSs; computers running enterprise apps do not share state with the DB server; instead messages--SQL commands/queries and their results--are exchanged between client and server, and higher levels of synchronization are handled on top of the IPC mechanism).

Encapsulating and hiding state seems to be one of those questionable 'best practices' that causes lots of unnecessary headaches (e.g. for persistence, maintenance, upgrade, extension, live programming). I came to a similar conclusion in my article local state is poison.

I wonder how much I was influenced by this paper. I remember having read it, but don't remember the details, and my conclusion seems to come from a different direction.

In any case, external (hence accessible) named state can still be secured, e.g. using cryptographic names (PKI or HMAC or proof-of-work or sparse capabilities) or secure partitioning (chroot sandbox, directory caps, opaque paths).

...closures and state certainly give you all the raw ingredients you need.

(* An "AOP-style fixed point" -- use backpatching to build a recursive function,
   and then return the ref cell (aka join point) so people can mutate it.
   Peter Landin may have invented this method, btw -- though he was too 
   disciplined to let the ref cell escape!
*)

let aop_fix f =
  let joinpoint = ref (fun _ -> assert false) in
  let () = joinpoint := f (fun z -> !joinpoint z) in
  ((fun z -> !joinpoint z), joinpoint)

(* Here's how you can add before and after advice to a function. By 
   updating the joinpoint/recursive-ref, we can add code to be run on
   recursive calls to a function.
*)

let before_advice advice joinpoint =
  let f = !joinpoint in 
  joinpoint := (fun x -> let () = advice x in f x)

let after_advice advice joinpoint =
  let f = !joinpoint in
  joinpoint := (fun x ->
		  let v = f x in
		  let () = advice x v in
		    v)

(* Of course, every example must be factorial. Notice that we get a 
   function we can call, as well as a join point fjoin. 
*)

let (fact, fjoin) =
  aop_fix (fun fact n -> if n = 0 then 1 else n * fact (n - 1))

(* Add some advice to log what the argument is. *) 

let () =
   before_advice (fun n -> Format.printf "Called with: %d\n" n) fjoin

(* We get the following results *)

# fact 5;;
Called with: 5
Called with: 4
Called with: 3
Called with: 2
Called with: 1
Called with: 0

- : int = 120

Cflow cannot be simulated this way, since it's basically reflection on your continuation. Of course, since it positively grinds contextual equivalences into dust, this is probably a good thing. :)