[Python-ideas] Message passing syntax for objects

[Haoyi Li]

There are basically two discussions happening here: ADTs (small objects
with public contents) vs Encapsulation, and method calls vs message sends.
A few responses:

>> or ensuring messages are handled serially per-object,

>This happens in either paradigm.

I mean that messages sent *from multiple threads *are handled serially. 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

These are definitely not things you get in either paradigm, and are
probably the main reasons people use actors in Scala: they don't use them
because they want a funky function call syntax, or they don't like static
checking for unknown messages! It really does give you a lot of nice things
in return for the funky "function call" (message send) syntax

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

- Want to do normal-list-things on your list-within-list? just use map()
filter() reduce() or list comprehension. Want to do normal list things to
you special InsnList object which isn't a normal list? Also much more
annoying.

- Want to get something out of a list-within-list? just use square braces
list_in_list[i][j]. Want to get something out of the special InsnList
object? You'll need to look up the magic method to call (or message to
send) to do it.

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.

In reality, nobody is ever going to re-use either your special InsnList
object or my list-of-lists-of-instructions. However, when they're working
with my list-of-lists, at least they can re-use *other* existing
list-handling functions to manipulate it, and not have to dig through my
docs to see what methods (or messages) my InsnList exposes.

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.


On Thu, Mar 21, 2013 at 9:37 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Mark Janssen writes:
>  > On Mon, Mar 18, 2013 at 7:14 PM, Haoyi Li <haoyi.sg at gmail.com> wrote:
>
>  > > I think this is a significant point: small things (lists, tuples,
>  > > primitives) are kept as structs and the data inside them is
>  > > manipulated directly,
>  >
>  > 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.
>
> I don't see the distinction you're aiming at.  PyPI, for example, is
> full of extremely complicated data structures that get reused.  Some
> of them get reused fairly frequently, though not as often as simple
> lists and tuples.
>
>  > Because there is no unified data model.
>
> That I can agree with, as an absolute.<wink/>
>
>  > > Having a simple thing (like a list or a tuple) with encapsulation
>  > > and sending messages to it is as silly [...]
>  >
>  > Ah, but you see I'm envisioning a data ecosystem (to borrow a
>  > phrase) for the Internet.  A peer-2-peer model for sharing data.
>  > So sending messages isn't so silly.
>
> Sure.  Smalltalk proved that.  But it's also not a universal
> improvement over the algebraic model of objects and operators, or
> function and method calling, and so on.  It can already be emulated in
> Python (including the "ignoring messages you don't understand" aspect,
> AFAIK) by using properties to turn what look like attribute references
> into method calls (or with a rather uglier syntax, dict references).
>
> I can see the advantage to you for your very specialized (at present,
> anyway) research project of a fairly radical change to Python syntax,
> but I don't see an advantage to the vast majority of Python users?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130321/e94fb0f9/attachment.html>