On May 10, 8:31 am, Jacob Lee <[EMAIL PROTECTED]> wrote: > Funny enough, I'm working on a project right now that is designed for > exactly that: PARLEY,http://osl.cs.uiuc.edu/parley. (An announcement > should show up in clp-announce as soon as the moderators release it). My > essential thesis is that syntactic sugar should not be necessary -- that a > nice library would be sufficient.
Synsugar is helpfull when you want to control compiler actions. Of course you can do this also by means of __special__ attributes but I guess this becomes clutter when you work with certain exposed sections in the code. > I do admit that Erlang's pattern > matching would be nice, although you can get pretty far by using uniform > message formats that can easily be dispatched on -- the tuple > (tag, sender, args, kwargs) > in the case of PARLEY, which maps nicely to instance methods of a > dispatcher class. Yes, I do think so too. It is more interesting to think about what might be qualify as a message. Destructuring it is not hard in anyway and I do also have a few concerns with naive pattern matching: http://www.fiber-space.de/EasyExtend/doc/gallery/gallery.html#4._Chainlets_and_the_switch-statement > The questions of sharing among multiple physical processes is interesting. > Implicit distribution of actors may not even be necessary if it is easy > enough for two hosts to coordinate with each other. In terms of the > general question of assigning actors to tasklets, threads, and processes, > there are added complications in terms of the physical limitations of > Python and Stackless Python: > - because of the GIL, actors in the same process do not gain the > advantag of true parallel computation > - all tasklet I/O has to be non-blocking > - tasklets are cooperative, while threads are preemptive > - communication across processes is slower, has to be serialized, etc. > - using both threads and tasklets in a single process is tricky Actors don't need locking primitives since their data is locked by virtue of the actors definition. That's also why I'm in favour for a runtime / compiler based solution. Within the shiny world of actors and actresses the GIL has no place. So a thread that runs actors only, does not need to be blocked or block other threads - at least not for data locking purposes. It is used much like an OS level process with better sharing capabilities ( for mailbox addresses and messages ). Those threads shall not take part of the access/release GIL game. They might also not be triggered explicitely using the usual threading API. > PARLEY currently only works within a single process, though one can choose > to use either tasklets or threads. My next goal is to figure out I/O, at > which point I get to tackle the fun question of distribution. > > So far, I've not run into any cases where I've wanted to change the > interpreter, though I'd be interested in hearing ideas in this direction > (especially with PyPy as such a tantalizing platform!). > -- > Jacob Lee <[EMAIL PROTECTED]> I guess you mean tantalizing in both of its meanings ;) Good luck and inform us when you find interesting results. Kay -- http://mail.python.org/mailman/listinfo/python-list
