Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[David Nolen]

On Mon, Feb 13, 2012 at 2:07 PM, Kurt Stephens  wrote:

> On 2/13/12 12:58 PM, David Nolen wrote:
> > Clojure is another Lisp that puts Objects at the bottom. Depending on
> > how its implemented I don't think it needs to be complex - for example
> > ClojureScript is hosted on JavaScript (which brings it's own Objects)
> > and the ClojureScript compiler is only about 1200 lines of Clojure. And
> > it delivers on the good onstage/backstage separation that Kiczales talks
> > about.
> Does Clojure, as it's designed, have the choice of not being being
> implemented on top of Objects?
> For example, has anybody implemented Clojure on Scheme?  Would it be
> smaller?
>

Clojure is definitely biased towards hosts which have some notion of
Objects - thus it works well on the CLR, JVM, and JavaScript. I'm sure you
could implement Clojure in Scheme but I think you would need to implement
an object system in Scheme first - though probably something like TinyCLOS
would be sufficient.

I think Lisp -> Objects might not be as nice as Objects -> Lisp. The second
approach, while possibly requiring more implementation work, provides users
rich opportunities to manipulate the machinery backstage. In the first
approach, users might not be able circumvent limitations of baked in
primitives like cons.

David
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

On 2/13/12 12:58 PM, David Nolen wrote:
> Clojure is another Lisp that puts Objects at the bottom. Depending on
> how its implemented I don't think it needs to be complex - for example
> ClojureScript is hosted on JavaScript (which brings it's own Objects)
> and the ClojureScript compiler is only about 1200 lines of Clojure. And
> it delivers on the good onstage/backstage separation that Kiczales talks
> about. 
Does Clojure, as it's designed, have the choice of not being being
implemented on top of Objects?
For example, has anybody implemented Clojure on Scheme?  Would it be
smaller?

I don't know enough about Clojure.  :(  More things to play with!  :)

> David
Kurt

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[David Nolen]

Clojure is another Lisp that puts Objects at the bottom. Depending on how
its implemented I don't think it needs to be complex - for example
ClojureScript is hosted on JavaScript (which brings it's own Objects) and
the ClojureScript compiler is only about 1200 lines of Clojure. And it
delivers on the good onstage/backstage separation that Kiczales talks
about.

David

On Sat, Feb 11, 2012 at 8:23 PM, Kurt Stephens  wrote:

>
> COLAs or CLOAs? : are lambda systems fundamentally simpler than object
> systems?
>
> Should Combined-Object-Lambda-**Archtecture really be
> Combined-Lambda-Object-**Architecture?
>
> Ian Piumarta’s IDST bootstraps a object-system, then a compiler, then a
> lisp evaluator.  Maru bootstraps a lisp evaluator, then crafts an object
> system, then a compiler.  Maru is much smaller and elegant than IDST.
>
> Are object systems necessarily more complex than lambda evaluators?  Or is
> this just another demonstration of how Lisp code/data unification is more
> powerful?
>
> If message send and function calls are decomposed into lookup() and
> apply(), the only difference basic OO message-passing and function calling
> is lookup(): the former is late-bound, the latter is early bound (in the
> link-editor, for example.).  Is OO lookup() the sole complicating factor?
>  Is a lambda-oriented compiler fundamentally less complex than a OO
> compiler?
>
> I took the object->lambda approach in TORT (http://github.com/kstephens/**
> tort ) tried to keep the OO kernel
> small, and delay the compiler until after the lisp evaluator.  The object
> system started out “tiny” but to support the lisp evaluator created in an
> OO-style (which the REPL and compiler is built on) required a lot of basic
> foundational object functionality.  Despite its name, TORT is no longer
> tiny; I probably didn’t restrain myself enough; it tries too much to
> support C extension and dynamic linking.
>
> Did Gregor Kiczales, Ian and others stumble upon the benefits of
> lisp->object bootstrapping .vs. object->lisp bootstrapping?  I’ve written
> object-oriented LISPs before 
> (http://github.com/kstephens/**llbased on 
> ideas from OAKLISP).  Do OO techniques make language
> implementation “feel” easier in the beginning, only to complect later on?
>
>  Just some ideas,
>  Kurt Stephens
>
> http://kurtstephens.com/node/**154 
>
>
> __**_
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/**listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

On 2/12/12 9:56 PM, Julian Leviston wrote:
> On 13/02/2012, at 2:47 PM, Kurt Stephens wrote:
>> Read Ian Piumarta's "Open, extensible object models"
>> ( http://piumarta.com/software/cola/objmodel2.pdf ).
>> ...
> 
> Ian's object model didn't actually reify message though, did
> it? 

No, it didn't.

I should go read it more. I wish that it was more accessible to me,
> and/or that I could somehow increase my ability to comprehend it. Any
> further recommendations for things to read along this lines? I'm QUITE
> interested (this was my favourite part of the FoNC project to a point).
> 

Keep reading.  I force myself to read things I don't understand until I do.
This mailing list is a great resource to become aware of good papers,
books, viewpoints, ideas, etc.  Don't give up.

>> REST is not object messaging or HTTP.
> REST works over HTTP. It can be object messaging, can't it? At least, as
> far as my understanding and implementations have gone. Maybe I'm deluded.

AFIAK, REST does not necessarily require HTTP, however there are natural
mappings between actions on a resource and HTTP actions:

http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf
http://roy.gbiv.com/untangled/

-- KAS
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Julian Leviston]

Hiya,

On 13/02/2012, at 2:47 PM, Kurt Stephens wrote:

> Read Ian Piumarta's "Open, extensible object models" ( 
> http://piumarta.com/software/cola/objmodel2.pdf ).
> At a certain level, send(), lookup() and apply() have bootstrap 
> implementations to break the infinite regress.  TORT was directly inspired by 
> Ian's paper.  MOS (written a while ago) has a very similar object model and 
> short-circuit.  There is an object, well-known by the system, that describes 
> its self -- this is where the short-circuit lives.
> 

Yeah I've read it about 20 times. I found it quite difficult... (mostly because 
of the fact that I didn't understand some of the C idioms, but also because the 
architecture was difficult to comprehend for me in general). Ian's object model 
didn't actually reify message though, did it? I should go read it more. I wish 
that it was more accessible to me, and/or that I could somehow increase my 
ability to comprehend it. Any further recommendations for things to read along 
this lines? I'm QUITE interested (this was my favourite part of the FoNC 
project to a point).

> A graph of TORT's object model is here: 
> http://kurtstephens.com/pub/tort/tort.svg .  It's turtles all the way down, 
> er... um... to the right.  The last turtle, the "method table", is chewing 
> its tail. :)
> 
>>> I'm not a fan of HTTP/SOAP bloat.  The fundamentals are often bulldozed by 
>>> it.
>> 
>> How about REST?
>> 
> REST is not object messaging or HTTP.
> 

REST works over HTTP. It can be object messaging, can't it? At least, as far as 
my understanding and implementations have gone. Maybe I'm deluded.


> -- Kurt
> 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

On 2/12/12 4:11 PM, Julian Leviston wrote:

On 13/02/2012, at 6:01 AM, Kurt Stephens wrote:

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()

...


I don't follow why a "message" isn't simply a token.

> For example, in Ruby, a message is simply a symbol, is it not?

You are confusing the name of a method (its selector), used to locate 
the method, for the message.  The message contains the selector, 
receiver, arguments, and in the case of Ruby, an optional block -- 
everything need to pass data and transfer control.  The selector 
represents many methods -- the actual behavior is in the method.  In 
some object systems (TORT) selectors and methods can be anonymous.


> One has to draw the line in the sand at some point.
> Why bother building an entire object for something which simply holds 
reference to a Method name

> (or not, as the case may be)?
> In this case, the media *is* the message, is it not? ;-) or are
> you stipulating that a Message would know how to perform lookup and 
call,
> and therefore warrants an entire class... the only issue here is that 
 of efficiency, isn't it?


Why draw a line at all?  The elements of the message are already there, 
at least in CRuby, but are buried in the C stack -- not visible to the 
user in an organized manner.  TORT allocates Message objects on the C 
stack, however a Message object does not need to "exist" until it's 
referenced.


In TORT, the receiver's method table implements lookup(msg) and the 
located method implements apply(msg, rcvr, args...); in fact, all 
objects in TORT implement apply(), most of them raise an error when 
apply() is called (similar to Self's code slot).  The message object, 
not the receiver, is always the first implicit argument.


I could imagine Message implementing both lookup() and apply(), but it 
could be delegated to any other object(s), or replacing the default 
object responsible for send() with another that prints traces then 
delegates to some other object.


Message.apply() could act like invoking a continuation.  You could take 
a Message, install it as a method somewhere and restart it.



Sorry if I'm asking really obviously answerable questions. Please bear with me. 
I'm eager to learn.

Another question I have, is, how do you solve the obvious recursive quality of 
having
> Message.new(sel, scr, args) and also then sending messages to the 
message object?

> Is "new" the bottom-out point?




Read Ian Piumarta's "Open, extensible object models" ( 
http://piumarta.com/software/cola/objmodel2.pdf ).
At a certain level, send(), lookup() and apply() have bootstrap 
implementations to break the infinite regress.  TORT was directly 
inspired by Ian's paper.  MOS (written a while ago) has a very similar 
object model and short-circuit.  There is an object, well-known by the 
system, that describes its self -- this is where the short-circuit lives.


A graph of TORT's object model is here: 
http://kurtstephens.com/pub/tort/tort.svg .  It's turtles all the way 
down, er... um... to the right.  The last turtle, the "method table", is 
chewing its tail. :)



I'm not a fan of HTTP/SOAP bloat.  The fundamentals are often bulldozed by it.


How about REST?


REST is not object messaging or HTTP.

-- Kurt

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Julian Leviston]

On 13/02/2012, at 6:01 AM, Kurt Stephens wrote:

> 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.
> 

I don't follow why a "message" isn't simply a token. For example, in Ruby, a 
message is simply a symbol, is it not? One has to draw the line in the sand at 
some point. Why bother building an entire object for something which simply 
holds reference to a Method name (or not, as the case may be)? In this case, 
the media *is* the message, is it not? ;-) or are you stipulating that a 
Message would know how to perform lookup and call, and therefore warrants an 
entire class... the only issue here is that  of efficiency, isn't it?

Sorry if I'm asking really obviously answerable questions. Please bear with me. 
I'm eager to learn.

Another question I have, is, how do you solve the obvious recursive quality of 
having Message.new(sel, scr, args) and also then sending messages to the 
message object? Is "new" the bottom-out point?


>> 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.

How about REST?

> 
>> Cheers,
>> Steve
>> 
> 
> -- Kurt

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[John Zabroski]

Applying the Linda analogy to object systems has been done before, perhaps most 
notably by Ehud Shapiro's work on Concurrent Prolog. Ehud once wrote a reply to 
Gertner in the Communications of the ACM, explaining how he could implement 
Tuple-space programs as logic programs. The Dining Philosopher's Problem was 
used as an example.

Even more recently we have things like TeaTime which furthers the tuple-space 
example with infinite backtracking. More broadly, Linda is just another 
implementation of the fully decoupled Observer pattern, where the Subject is 
decoupled from the Observer by a Registry object. TeaTime can then be seen as a 
further generalization to allow for multi-version concurrency control. Other 
systems and/or languages use the Observer pattern as a litnus test for type 
safety or true "safe" mutable state. Some people describe the problem in very 
weak languages as Callback Hell, because an unsafe non decoupled Ovserver 
pattern implementation doesn't have a fairness strategy or way to prioritize 
Observers out of the box. For example, should the first object to get a 
notification from the subject be the first to reply? What about race conditions 
and dirty reads due to the first ovserver causing a second change notification 
from the Subject?

It turns out these strategies like fairness and message prioritization can be 
built from a trustworthy core - as shown in the E language and first 
hypothesized by Hewitt in his Actor Model. In the Actor Model an actor can 
reorder messages and thus decide priority, even providing fairness which the 
Actor Model axioms say nothing about. In E, communication is handled by 'vats' 
which are essentially a different way to implement a Registry object to fully 
decouple the Subject and Observer and still provide fair resource allocation. 
Yet, E lacks static well-defined types for reasoning about behavior. So type 
theorists come along and ask if they can make a type safe Observable behavior 
that addresses these concerns - see Scala for example.

Hope this perspective on history helps.

Cheers, 
Z-Bo

Sent from my Droid Charge on Verizon 4GLTE

--Original Message--
From: Hans-Martin Mosner 
To: "Fundamentals of New Computing" 
Date: Sunday, February 12, 2012 8:19:37 PM GMT+0100
Subject: Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler 
than object systems?

Am 12.02.2012 20:01, schrieb Kurt Stephens:
> Many languages do not reify the message itself as an object.
>
I have been musing lately how the Linda model (tuple spaces) could be helpful.
Tuples can be understood as messages sent to an anonymous receiver (whoever 
does a "get" with a matching signature).
One nice analogy is that cell biology works pretty similar to that - proteins 
and other molecules are built from
constituents, flot freely (more or less) in the cytoplasm and cause effects 
when they bind to a matching site.
Of course, programming on this level alone seems pretty tedious - I don't know 
how well it scales to higher abstraction
levels. But it does have some nice practical consequences:
- the state of the system is defined by the tuples, so snapshotting and 
in-place software upgrading is relatively painless
- it lends itself well to parallelisation and distribution

Cheers,
Hans-Martin
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

On 2/12/12 1:19 PM, Hans-Martin Mosner wrote:

Am 12.02.2012 20:01, schrieb Kurt Stephens:

Many languages do not reify the message itself as an object.


I have been musing lately how the Linda model (tuple spaces) could be helpful.


We've been using tuple spaces at my current job for 5+ years.  It is too 
low-level for distributing object messages.  It feels a little too 
"lispy", to boot.  :)  The Linda model is a distribution abstraction 
that doesn't fit very well into a "Web SOA", there's too much 
HTTP-centrism now to ignore.


It's *very* likely we will replace it with ASIR framework described in 
my slides.  One could implement a Tuple space (or HTTP) Transport with it.




Cheers,
Hans-Martin


-- Kurt
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[John Zabroski]

Hi Kurt,

Lisp is more expressive than lambda alone since Lisp contains forms that cannot 
be represented by lambda directly - an encoding must be used. A novel 
explanation of this math phenomena can be found in Barry Jay's recent book, 
Pattern Calculus, published via Springer-Verlag. But very briefly, pattern 
matching is more general than beta reduction used in the lambda calculus.

I hope this pointer will help you work through your intuition, but the hard 
work is on you since reading Barry's book has some pre-reqs. ;)

Barry does read this list here and there, fyi.



Sent from my Droid Charge on Verizon 4GLTE

--Original Message--
From: Kurt Stephens 
To: "Fundamentals of New Computing" 
Date: Saturday, February 11, 2012 7:23:01 PM GMT-0600
Subject: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than 
object systems?


COLAs or CLOAs? : are lambda systems fundamentally simpler than object 
systems?

Should Combined-Object-Lambda-Archtecture really be 
Combined-Lambda-Object-Architecture?

Ian Piumarta’s IDST bootstraps a object-system, then a compiler, then a 
lisp evaluator.  Maru bootstraps a lisp evaluator, then crafts an object 
system, then a compiler.  Maru is much smaller and elegant than IDST.

Are object systems necessarily more complex than lambda evaluators?  Or 
is this just another demonstration of how Lisp code/data unification is 
more powerful?

If message send and function calls are decomposed into lookup() and 
apply(), the only difference basic OO message-passing and function 
calling is lookup(): the former is late-bound, the latter is early bound 
(in the link-editor, for example.).  Is OO lookup() the sole 
complicating factor?  Is a lambda-oriented compiler fundamentally less 
complex than a OO compiler?

I took the object->lambda approach in TORT 
(http://github.com/kstephens/tort) tried to keep the OO kernel small, 
and delay the compiler until after the lisp evaluator.  The object 
system started out “tiny” but to support the lisp evaluator created in 
an OO-style (which the REPL and compiler is built on) required a lot of 
basic foundational object functionality.  Despite its name, TORT is no 
longer tiny; I probably didn’t restrain myself enough; it tries too much 
to support C extension and dynamic linking.

Did Gregor Kiczales, Ian and others stumble upon the benefits of 
lisp->object bootstrapping .vs. object->lisp bootstrapping?  I’ve 
written object-oriented LISPs before (http://github.com/kstephens/ll 
based on ideas from OAKLISP).  Do OO techniques make language 
implementation “feel” easier in the beginning, only to complect later on?

   Just some ideas,
   Kurt Stephens

http://kurtstephens.com/node/154


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Hans-Martin Mosner]

Am 12.02.2012 20:01, schrieb Kurt Stephens:
> Many languages do not reify the message itself as an object.
>
I have been musing lately how the Linda model (tuple spaces) could be helpful.
Tuples can be understood as messages sent to an anonymous receiver (whoever 
does a "get" with a matching signature).
One nice analogy is that cell biology works pretty similar to that - proteins 
and other molecules are built from
constituents, flot freely (more or less) in the cytoplasm and cause effects 
when they bind to a matching site.
Of course, programming on this level alone seems pretty tedious - I don't know 
how well it scales to higher abstraction
levels. But it does have some nice practical consequences:
- the state of the system is defined by the tuples, so snapshotting and 
in-place software upgrading is relatively painless
- it lends itself well to parallelisation and distribution

Cheers,
Hans-Martin
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

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 mailto:j...@hapra.at>> 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
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Casey Ransberger]

There's always

http://en.wikipedia.org/wiki/Actor_model

and

http://www.dalnefre.com/wp/humus/

...which seem to make concurrency less of a PITA. Like most languages that
crystalize a particular style, though, there's some learning involved for
folks (like me!) who hadn't really thought about the actor model in a deep
way.

On Sun, Feb 12, 2012 at 9:15 AM, Steve Wart  wrote:

> Simplicity, like productivity, is an engineering metric that can only be
> measured in the context of a particular application. Most successful
> programming languages aren't "mathematically pure" but some make it easier
> than others to use functional idioms (by which I mean some mechanism to
> emulate the types of operations you describe below). However many problems
> are simpler to solve without such abstractions. That's why "practical
> languages" like Smalltalk-80 and Lisp and their mainstream derivatives have
> succeeded over their more pure counterparts.
>
> I think I responded to this message because I was sick in bed yesterday
> reading the intro paragraphs of The Algorithmic Beauty of Plants yesterday (
> http://algorithmicbotany.org/papers/#abop), and shared the introduction
> of DOL-systems with my son. We both enjoyed it, but I'm not sure how this
> translates into reasoning about distributed systems.
>
> 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.
>
> 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.
>
> HTTP seems to have avoided this by using MIME types, but this is more
> about agreed upon engineering standards rather than computational
> abstractions.
>
> Cheers,
> Steve
>
>
> On Sun, Feb 12, 2012 at 4:02 AM, Jakob Praher  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
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>


-- 
Casey Ransberger
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Steve Wart]

Simplicity, like productivity, is an engineering metric that can only be
measured in the context of a particular application. Most successful
programming languages aren't "mathematically pure" but some make it easier
than others to use functional idioms (by which I mean some mechanism to
emulate the types of operations you describe below). However many problems
are simpler to solve without such abstractions. That's why "practical
languages" like Smalltalk-80 and Lisp and their mainstream derivatives have
succeeded over their more pure counterparts.

I think I responded to this message because I was sick in bed yesterday
reading the intro paragraphs of The Algorithmic Beauty of Plants yesterday (
http://algorithmicbotany.org/papers/#abop), and shared the introduction of
DOL-systems with my son. We both enjoyed it, but I'm not sure how this
translates into reasoning about distributed systems.

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.

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.

HTTP seems to have avoided this by using MIME types, but this is more about
agreed upon engineering standards rather than computational abstractions.

Cheers,
Steve

On Sun, Feb 12, 2012 at 4:02 AM, Jakob Praher  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
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Jakob Praher]

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

Am 12.02.12 03:20, schrieb Steve Wart:
> I think of OO as an organization mechanism. It doesn't add
> fundamentally to computation, but it allows complexity to be managed
> more easily.
>
> On Sat, Feb 11, 2012 at 5:23 PM, Kurt Stephens  > wrote:
>
>
> COLAs or CLOAs? : are lambda systems fundamentally simpler than
> object systems?
>
> Should Combined-Object-Lambda-Archtecture really be
> Combined-Lambda-Object-Architecture?
>
> Ian Piumarta's IDST bootstraps a object-system, then a compiler,
> then a lisp evaluator.  Maru bootstraps a lisp evaluator, then
> crafts an object system, then a compiler.  Maru is much smaller
> and elegant than IDST.
>
> Are object systems necessarily more complex than lambda
> evaluators?  Or is this just another demonstration of how Lisp
> code/data unification is more powerful?
>
> If message send and function calls are decomposed into lookup()
> and apply(), the only difference basic OO message-passing and
> function calling is lookup(): the former is late-bound, the latter
> is early bound (in the link-editor, for example.).  Is OO lookup()
> the sole complicating factor?  Is a lambda-oriented compiler
> fundamentally less complex than a OO compiler?
>
> I took the object->lambda approach in TORT
> (http://github.com/kstephens/tort) tried to keep the OO kernel
> small, and delay the compiler until after the lisp evaluator.  The
> object system started out "tiny" but to support the lisp evaluator
> created in an OO-style (which the REPL and compiler is built on)
> required a lot of basic foundational object functionality.
>  Despite its name, TORT is no longer tiny; I probably didn't
> restrain myself enough; it tries too much to support C extension
> and dynamic linking.
>
> Did Gregor Kiczales, Ian and others stumble upon the benefits of
> lisp->object bootstrapping .vs. object->lisp bootstrapping?  I've
> written object-oriented LISPs before
> (http://github.com/kstephens/ll based on ideas from OAKLISP).  Do
> OO techniques make language implementation "feel" easier in the
> beginning, only to complect later on?
>
>  Just some ideas,
>  Kurt Stephens
>
> http://kurtstephens.com/node/154
>
>
> ___
> fonc mailing list
> fonc@vpri.org 
> http://vpri.org/mailman/listinfo/fonc
>
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Steve Wart]

I think of OO as an organization mechanism. It doesn't add fundamentally to
computation, but it allows complexity to be managed more easily.

On Sat, Feb 11, 2012 at 5:23 PM, Kurt Stephens  wrote:

>
> COLAs or CLOAs? : are lambda systems fundamentally simpler than object
> systems?
>
> Should Combined-Object-Lambda-**Archtecture really be
> Combined-Lambda-Object-**Architecture?
>
> Ian Piumarta’s IDST bootstraps a object-system, then a compiler, then a
> lisp evaluator.  Maru bootstraps a lisp evaluator, then crafts an object
> system, then a compiler.  Maru is much smaller and elegant than IDST.
>
> Are object systems necessarily more complex than lambda evaluators?  Or is
> this just another demonstration of how Lisp code/data unification is more
> powerful?
>
> If message send and function calls are decomposed into lookup() and
> apply(), the only difference basic OO message-passing and function calling
> is lookup(): the former is late-bound, the latter is early bound (in the
> link-editor, for example.).  Is OO lookup() the sole complicating factor?
>  Is a lambda-oriented compiler fundamentally less complex than a OO
> compiler?
>
> I took the object->lambda approach in TORT (http://github.com/kstephens/**
> tort ) tried to keep the OO kernel
> small, and delay the compiler until after the lisp evaluator.  The object
> system started out “tiny” but to support the lisp evaluator created in an
> OO-style (which the REPL and compiler is built on) required a lot of basic
> foundational object functionality.  Despite its name, TORT is no longer
> tiny; I probably didn’t restrain myself enough; it tries too much to
> support C extension and dynamic linking.
>
> Did Gregor Kiczales, Ian and others stumble upon the benefits of
> lisp->object bootstrapping .vs. object->lisp bootstrapping?  I’ve written
> object-oriented LISPs before 
> (http://github.com/kstephens/**llbased on 
> ideas from OAKLISP).  Do OO techniques make language
> implementation “feel” easier in the beginning, only to complect later on?
>
>  Just some ideas,
>  Kurt Stephens
>
> http://kurtstephens.com/node/**154 
>
>
> __**_
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/**listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Kurt Stephens]

COLAs or CLOAs? : are lambda systems fundamentally simpler than object 
systems?


Should Combined-Object-Lambda-Archtecture really be 
Combined-Lambda-Object-Architecture?


Ian Piumarta’s IDST bootstraps a object-system, then a compiler, then a 
lisp evaluator.  Maru bootstraps a lisp evaluator, then crafts an object 
system, then a compiler.  Maru is much smaller and elegant than IDST.


Are object systems necessarily more complex than lambda evaluators?  Or 
is this just another demonstration of how Lisp code/data unification is 
more powerful?


If message send and function calls are decomposed into lookup() and 
apply(), the only difference basic OO message-passing and function 
calling is lookup(): the former is late-bound, the latter is early bound 
(in the link-editor, for example.).  Is OO lookup() the sole 
complicating factor?  Is a lambda-oriented compiler fundamentally less 
complex than a OO compiler?


I took the object->lambda approach in TORT 
(http://github.com/kstephens/tort) tried to keep the OO kernel small, 
and delay the compiler until after the lisp evaluator.  The object 
system started out “tiny” but to support the lisp evaluator created in 
an OO-style (which the REPL and compiler is built on) required a lot of 
basic foundational object functionality.  Despite its name, TORT is no 
longer tiny; I probably didn’t restrain myself enough; it tries too much 
to support C extension and dynamic linking.


Did Gregor Kiczales, Ian and others stumble upon the benefits of 
lisp->object bootstrapping .vs. object->lisp bootstrapping?  I’ve 
written object-oriented LISPs before (http://github.com/kstephens/ll 
based on ideas from OAKLISP).  Do OO techniques make language 
implementation “feel” easier in the beginning, only to complect later on?


  Just some ideas,
  Kurt Stephens

http://kurtstephens.com/node/154


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc