<div dir="ltr"><div class="im" style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34);font-family:arial;font-size:small">There are basically two discussions happening here: ADTs (small objects with public contents) vs Encapsulation, and method calls vs message sends. A few responses:</span><br>

</div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px">>> or ensuring messages are handled serially per-object,<br><br>

</div><span style="font-family:arial,sans-serif;font-size:13px">>This happens in either paradigm.</span><br><div class="gmail_extra"><br></div><div class="gmail_extra">I mean that messages sent <i>from multiple threads </i>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:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">- its own single-threaded event loop to run its methods</div><div class="gmail_extra">- without the performance hit of creating lots and lots of threads</div><div class="gmail_extra" style>

- 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</div><div class="gmail_extra" style>- with minimal overhead over standard method calls (both syntactic and performance)</div>

<div class="gmail_extra">- for zero effort on the part of the programmer</div><div class="gmail_extra"><br></div><div class="gmail_extra">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</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">>Yes, and here is where something significant I think will happen.</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">Complicated data structures just simply don't get re-used.  Python</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">allows lists within lists within lists, but any program that uses that</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">outside of n x n matrices won't ever get re-used ever.  Because there</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">i</span><span style="font-family:arial,sans-serif;font-size:13px">s no unified data model.</span></div>

<div class="gmail_extra"><br></div><div class="gmail_extra" style>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:</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>- 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.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>- 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.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>- 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.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>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 <i>your</i> way of doing things rather than the standard python-list way of doing things.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>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 <i>other</i> existing list-handling functions to manipulate it, and not have to dig through my docs to see what methods (or messages) my InsnList exposes.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>In the end, message sends and method calls are basically isomorphic, so much so that in Scala you can <a href="http://doc.akka.io/docs/akka/2.1.0/scala/typed-actors.html">transparently convert method calls to message sends under the hood</a> 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.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 9:37 AM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Mark Janssen writes:<br>
 > On Mon, Mar 18, 2013 at 7:14 PM, Haoyi Li <<a href="mailto:haoyi.sg@gmail.com">haoyi.sg@gmail.com</a>> wrote:<br>
<br>
</div><div class="im"> > > I think this is a significant point: small things (lists, tuples,<br>
 > > primitives) are kept as structs and the data inside them is<br>
 > > manipulated directly,<br>
 ><br>
 > Yes, and here is where something significant I think will happen.<br>
 > Complicated data structures just simply don't get re-used.  Python<br>
 > allows lists within lists within lists, but any program that uses<br>
 > that outside of n x n matrices won't ever get re-used ever.<br>
<br>
</div>I don't see the distinction you're aiming at.  PyPI, for example, is<br>
full of extremely complicated data structures that get reused.  Some<br>
of them get reused fairly frequently, though not as often as simple<br>
lists and tuples.<br>
<div class="im"><br>
 > Because there is no unified data model.<br>
<br>
</div>That I can agree with, as an absolute.<wink/><br>
<div class="im"><br>
 > > Having a simple thing (like a list or a tuple) with encapsulation<br>
 > > and sending messages to it is as silly [...]<br>
 ><br>
 > Ah, but you see I'm envisioning a data ecosystem (to borrow a<br>
 > phrase) for the Internet.  A peer-2-peer model for sharing data.<br>
 > So sending messages isn't so silly.<br>
<br>
</div>Sure.  Smalltalk proved that.  But it's also not a universal<br>
improvement over the algebraic model of objects and operators, or<br>
function and method calling, and so on.  It can already be emulated in<br>
Python (including the "ignoring messages you don't understand" aspect,<br>
AFAIK) by using properties to turn what look like attribute references<br>
into method calls (or with a rather uglier syntax, dict references).<br>
<br>
I can see the advantage to you for your very specialized (at present,<br>
anyway) research project of a fairly radical change to Python syntax,<br>
but I don't see an advantage to the vast majority of Python users?<br>
<br>
</blockquote></div><br></div></div>