On Saturday I was at the Lightweight Languages Workshop at MIT, and here are notes about some of the talks. There's a webcast available from the website.
Erlang
First talk was Erlang, which is very interesting. It's a functional language, and designed for concurrency - you can launch tens of thousands of processes, and pass messages between them. And this is done fast - 2 microseconds to start a process. Apparently Oz shares a lot of the concepts here as well.
OS-level services in Scheme
Second talk was about the ways PLT Scheme (MzScheme?) is incorporating OS-level functionality into the language.
PLT Scheme OS-like capabilities that I found interesting:
- killing threads cleanly
- Indepent GUI eventspaces (e.g. independent regarding modal dialogs).
- custodian manages resources for threads so you can easily shut it down.
- enforce abstractions (like Java's private?) and then add hooks for bypassing it for debugging.
This is very useful for IDEs. They have example IDE that lets you run say, infinite loop in interpreter, without the GUI freezing up, and because you can kill threads you can cancel this operation. In addition, GUI you program via IDE runs in its own event loop so it doesn't interfere with IDE's event loop.
Apparently the author is spending a lot of time making the blocking OS level facilities not block, so he can do this sort of thing.
Asynchronous Exceptions in Python
The fourth talk was about raising exceptions in signal handlers in Python, and the problem this causes. Basically the issue is that in e.g. this code:
f = open("file") try: s = f.read() finally: f.close()
the file may never be closed, since a signal might raise an exception right after file is opened but before try/finally. The obvious solution is too disable the signal around this code, but this is TOO MUCH TYPING, and you MIGHT FORGET to reenable the signal. So what was suggested? Adding new keywords! They gave following example code:
block: f = open("f") try: unblock: s = f.read() finally: f.close()
where block/unblock do that to signals. I think this is terribly wrong. First of all, their own example was wrong, it should actually have been:
block: f = open("f") try: unblock: s = f.read() finally: block: f.close() unblock: pass
This is totally ridiculous - you need to wrap each block of code this way, it blocks all signals instead of just the appropriate one, and the syntax totally violates the standard behavior of existing keyword pairs in python, since they are on different indentation levels.
I think raising exceptions from signal handlers is just a messy idiom, and they just shouldn't be doing it. And given you don't need a keyword to solve the problem, you just can use the signal module, their suggestion is just badly implemented syntactic sugar, with side effects that extend beyond the problem they want to solve.
I might write up the rest of the talks tommorow.