On 2/12/12 11:15 AM, Steve Wart wrote:
Can the distributed computation model you describe be formalized as a
set of rewrite rules, or is the "black box" model really about a
protocol for message dispatch? Attempts to build distributed messaging
systems haven't been particularly simple. In fact I consider both CORBA
and Web Services to be failures for that reason.
Perhaps it's because the "Message" in OO systems is often forgotten:
message passing is described as "calling a method", instead of "sending
a message".
Many languages do not reify the message itself as an object.
If send(sel, rcvr, args) can decomposed into apply(lookup(sel, rcvr,
args), rcvr, args), then this follows:
Message.new(sel, rcvr, args).lookup().apply()
Tort does this, so does MOS (
http://kurtstephens.com/pub/mos/current/src/mos/ ), however Ruby, for
example, does not -- not sure how many others do.
The Self Language handles apply() by cloning the method object,
assigning arguments into its slots, then transferring control to the
object's code slot. Yet, there is still no tangible Message object.
It's very difficult to use OO in this way without imposing excessive
knowledge about the internal representation of objects if you need to
serialize parameters or response objects.
Remembering there is an implicit Message object behind the scenes makes
message distribution a bottom-up abstraction, starting with identity
transforms:
http://kurtstephens.com/pub/abstracting_services_in_ruby/asir.slides/index.html
This doesn't fully remove the serialization issues, but those are
readily, and often already, solved. One generic serialization is
suitable for the parameters and the message objects; decomposed into
Request and Response objects. The Transport is then agnostic of
encoding/decoding details.
HTTP seems to have avoided this by using MIME types, but this is more
about agreed upon engineering standards rather than computational
abstractions.
I'm not a fan of HTTP/SOAP bloat. The fundamentals are often bulldozed
by it.
Cheers,
Steve
-- Kurt
On Sun, Feb 12, 2012 at 4:02 AM, Jakob Praher <[email protected]
<mailto:[email protected]>> wrote:
We would have to define what you mean by the term computation.
Computation is a way to transform a language "syntactically" by
defined rules.
The lambda calculus is a fundamental way of performing such
transformation via reduction rules (the alpha, beta, gamma rules).
In the end the beta-reduction is term substitution. But abstraction
and substitution in a generic purpose von Neumann-style computer has
to be modelled accordingly: A variable in the computer is a memory
location/a register that can be updated (but it is not a 1:1
correspondence). E.g. A function in a computer is jump to a certain
code location having to write to certain locations in
memory/registers to get the arguments passed.
IMHO the computational model of objects and method dispatch is more
of a black box / communcation-oriented model. One does not know much
about the destination and dispatchs a message interpreting the
result. In functional languages the model is more white boxed. One
can always decompose a term into subterms and interpret it.
Therefore functional languages do not grow easily to distributed
programming, where the knowledge over the terms is limited.
Best,
Jakob
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
