Lambda the Ultimate

The Actor model is a mathematical theory that treats “Actors” as the universal primitives of concurrent digital computation. The model has been used both as a framework for a theoretical understanding of concurrency, and as the theoretical basis for several practical implementations of concurrent systems. Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching. The advent of massive concurrency through client-cloud computing and many-core computer architectures has galvanized interest in the Actor model.

An Actor is a computational entity that, in response to a message it receives, can concurrently:
• send messages to addresses of Actors that it has;
• create new Actors;
• designate how to handle the next message it receives.

There is no assumed order to the above actions and they could be carried out concurrently. In addition two messages sent concurrently can be received in either order. Decoupling the sender from communication it sends was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages.

The Actor model can be used as a framework for modeling, understanding, and reasoning about, a wide range of concurrent systems. For example:
• Electronic mail (e-mail) can be modeled as an Actor system. Mail accounts are modeled as Actors and email addresses as Actor addresses.
• Web Services can be modeled with endpoints modeled as Actor addresses.
• Objects with locks (e.g. as in Java and C#) can be modeled as Actors.
• Functional and Logic programming implemented using Actors.

Actor technology will see significant application for integrating all kinds of digital information for individuals, groups, and organizations so their information usefully links together. Information integration needs to make use of the following information system principles:
• Persistence. Information is collected and indexed.
• Concurrency: Work proceeds interactively and concurrently, overlapping in time.
• Quasi-commutativity: Information can be used regardless of whether it initiates new work or become relevant to ongoing work.
• Sponsorship: Sponsors provide resources for computation, i.e., processing, storage, and communications.
• Pluralism: Information is heterogeneous, overlapping and often inconsistent. There is no central arbiter of truth
• Provenance: The provenance of information is carefully tracked and recorded

The Actor Model is intended to provide a foundation for inconsistency robust information integration.

See article at following location: Parallelism and Concurrency in the Actor Model

I came across an early post on the topic of disallowing shadowing (message quoted below):

In lambda calculus you can always rebind an already-bound name, but in
practice, there are lots of limitations imposed on rebinding in real
languages: top-level module bindings can't be redefined in mzscheme,
operations of type classes can't be redefined at the top level in
Haskell, etc. What happens if you take this to the extreme and disallow
shadowing entirely in a lexically scoped language? [1]

At first I thought this would cause problems for macros, but in a
hygienic system that renames everything to something fresh anyway, it
probably wouldn't matter.

Other than being an annoyance when you want to reuse a name for some
other purpose (which is arguably bad style anyway), what problems would
disallowing local rebinding cause?

Dave

[1] http://www.mail-archive.com/haskell@haskell.org/msg01268.html

There were a few follow-up discussions but did not expand further. Essentially I have the same question as Dave and I hope to hear more comments on it.
What is theoretical and practical consequence, say if we forbid shadowing in the lambda caluclus?

I noticed that CoffeeScript has gone toward the direction of forbid shadowing. Although raised a lot of opposition, the designer insisted on it. Is his point solid?