During the Clojure for Lispers talk in Boston (see clojure.blip.tv if you want to watch it), someone asked Rich about enforcing the no-side- effect rule in transactions. Rich answered that he couldn't do that, because "I'm a dynamic language." (audience got a chuckle out of that way of putting it :-)
I've been thinking a bit about ways to automatically check for side effects in transactions, for people that want to catch them and eliminate them. I know that they can be found by hand via various types of testing/debugging, but I'm curious how we might be able to do better. I was toying with a code walker that tried to check for whether some code had side effects or not, and now I see more clearly several of the difficulties of trying to statically check for such things. There are easy cases of determining that a function is pure, or has side effects, but there are lots of cases where it is tricky (and I'm sure in general undecidable, in the complexity theoretic sense of the word). Someone asked Rich about dynamic enforcement during the talk, and he answered that it might be possible. Of course, this won't guarantee that you've caught all possible side effects in transactions without "sufficient testing", but at least it will quickly catch them if you try to do one. I know there is an io! macro meant to flag an error if it is wrapped around code that you try to run during a transaction. That's cool. But currently almost nothing in the core libraries use it. It would certainly have some performance impact if all I/O routines used it. A couple of other ideas, although I don't know whether they have holes in them, or what their performance impact might be. (1) At the time of entering a transaction, dynamically bind all functions known to possibly cause side effects to a version that throws an exception. One down side is coming up with, and maintaining across changes to Clojure, that list of functions. Another is that such dynamic bindings do not propagate from thread to thread, so a different thread could call one of those side-effecting functions without causing any problems. Also, I'm not sure, but it might be possible for a "non cooperative" function to restore the original side-effecting version of one of those rebound functions. (2) Use Java sandboxing features to try to catch side effects. I suspect it might be possible to configure sandboxing to catch attempted I/O, but I'd be surprised if it can catch all kinds of side effects. I was hoping someone on the group might have more knowledge of Java sandboxing features and could comment. I also don't know what the performance impact of creating such a sandbox might be. Thanks, Andy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
