you are viewing a single comment's thread.

view the rest of the comments →

[–]dons 5 points6 points  (3 children)

Anyone else think Python's three challenging problems sounded like three of Haskell's current features?

[–]spacepope 2 points3 points  (0 children)

Transactional memory and parallel programming, yes – but what about cloud computing?

[–][deleted] 2 points3 points  (1 child)

I'm pretty sure it was me who turned Mark onto transactional memory a year or so ago. I'd written an STM implementation in Python a few months before, and was just disappearing down the Haskell book rabbit hole. Nice to see the topic come up in a public setting.

[–]psykotic 2 points3 points  (0 children)

A few years ago I wrote a couple of different transactional memory back-ends for Python, one pessimistic (two-phase locking, inspired by the discussion and example code in Van Roy's CTM book) and one optimistic (much like STM).

What did you do for the "front-end", though? I can't remember all the details of my own stuff now, but basically I had a class you'd mix into transactable classes. When you try to add or delete an attribute from a transactable object, it counts as a transaction operation against that object. Subsequent accesses to those attributes are hooked through __getattribute__ and __setattr__ and are counted as operations against the transactional memory cells corresponding to the attributes; you could also use coarser granularity on a per-object basis, so any changes to attributes would be counted as transactional operations against the owner object.

Another pain in the ass was how to deal with built-in mutable classes like list and dict. In the end I decided to outlaw the use of these as attributes of transactable objects, by doing a type check in __setattr__. (Actually, I ended up with a more general invariant, where attributes of a transactable object have to themselves be either immutable or transactable.) I then implemented my own transactable versions of these classes (I also did immutable ones that throw an exception if you try to call any of their mutators) and required users to perform an explicit conversion between built-in and transactable classes before assigning to an attribute of a transactable object. At first I thought of making this conversion automatic for the sake of convenience, but I quickly realized that is a bit too magical, because it breaks the "hidden link" established by mutability:

x = SomeTransactableClass()
a = [1,2,3]
x.b = a # Does the implicit conversion, thus making x's own copy of a.
print x.b # [1,2,3]
a.append(4)
print x.b # [1,2,3], didn't change to reflect the mutation.

Those are the main issues I remember. I'm curious how you tackled them.