[Python-ideas] Message passing syntax for objects

[Mark Janssen]

On Thu, Mar 21, 2013 at 11:08 AM, Haoyi Li <haoyi.sg at gmail.com> wrote:

> There are basically two discussions happening here: ADTs (small objects
> with public contents) vs Encapsulation, and method calls vs message sends.
> A few responses:
>
> Thank you.  You've boiled the discussion down to the two main elements.
 Abstract data type's (which I was calling "prototypes")  vs. Encapsulation
is the important distinction.  It's not an easy distinction to see from the
words alone.  The former, I'll say, is built from the ground (the bits)
upwards, while the latter, while the latter from the top (the
application-layer), downwards.  But, I wouldn't say that for ADTs that
public contents were the important part.  In fact, I'd argue the opposite.


> >> or ensuring messages are handled serially per-object,
>
> >This happens in either paradigm.
>
> I mean that messages sent *from multiple threads *are handled serially.
>

Well this is where it gets bizarre to me.  Because, despite threading, the
CPU still has to dispatch all processes and handle the data passing,
ultimately.


> If your entire program is single threaded (as many python programs are) or
> has a GIL which prevents multiple concurrent method calls, then i guess it
> isn't a big deal. But in a language that does have pre-emptive
> multithreading, this basically gives you a non-blocking, guaranteed
> (because there's no other way to interact with the object other than
> sending messages) "lock" around each object. Each object basically gets:
>
> - its own single-threaded event loop to run its methods
> - without the performance hit of creating lots and lots of threads
> - without the overhead of running multiple processes and IPC betweeen the
> one-thread-per-process event loops (twisted, node.js, etc.) when you want
> to utilize multiple cores
> - with minimal overhead over standard method calls (both syntactic and
> performance)
> - for zero effort on the part of the programmer
>

Well, I argue that in the world of programming language evolution, all of
these, except for the last, are premature optimizations.

>
> >Yes, and here is where something significant I think will happen.
> >Complicated data structures just simply don't get re-used.  Python
> >allows lists within lists within lists, but any program that uses that
> >outside of n x n matrices won't ever get re-used ever.  Because there
> >is no unified data model.
>
> I disagree completely. Coming from Java, where every list-within-list has
> its own special class to represent it, my experience is that is a terrible
> idea:
>
>
- Want to convert from one list-within-list to another list-within-list?
> Use a list comprehension and be done with it. Want to convert a special
> InsnList to a special ParameterList? Much more annoying.
>

How can you use a list comprehension unless you know the length or depth of
each sub-list?


> It's not like encapsulating the whole thing makes the data struture any
> less complicated: it just makes it more annoying to do things with, because
> now I have to learn *your* way of doing things rather than the standard
> python-list way of doing things.
>

Where that where the ClassName and the Class.__doc__ should get you half
the way there.  There necessary component would be a universal/abstract
data type.  I propose a FractalGraph which can handle and scale any level
of complexity. As long as we have a universal data type, the class
hierarchy that emerges will be simple and general to handle, rather than
dealing with personal taxonomies.


> In the end, message sends and method calls are basically isomorphic, so
> much so that in Scala you can transparently convert method calls to
> message sends under the hood<http://doc.akka.io/docs/akka/2.1.0/scala/typed-actors.html> if
> you prefer that syntax! Unless there's some significant advantage of doing
> it, it seems to me that the improvement would basically be forcing people
> to run a regex on their code to convert obj.method(a, b) to obj << (msg, a,
> b), and then life goes on exactly as it did before.
>

No.  While you're technically correct as to the issue of isomorphism.  In
practice, the usage you propose does not help whatsoever.  "(mgs, a, b)" is
too complex.  Firstly, in the message-passing scheme I'm proposing, you
never pass in more than one piece of data, unless it's a very structured,
perhaps (a single XML-like tree?).

mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130321/aba334eb/attachment.html>