On Mon, Jan 02, 2006 at 06:55:24PM -0500, Bob Rogers wrote: : [2] About two-thirds of the way through A06 (search for "temporize : object attributes"), Larry says that this will be done via : closures. In order to support rezipping, such a closure would need : to accept a new value to store and return the old value. Or maybe : the .TEMP method could just return a location PMC?
I would prefer the latter for the general case. As with any "rw" location, you're returning a proxy/location object with an appropriate lvalue interface. Any user-specified closures end up being methods of that object. Treating such a closure as the proxy object not only confuses getting with setting but also confuses both of those with the original identification of the location. I was not terribly consistent in carrying this idea though in the original Apocalypses. By the way, it's getting to be a bit dangerous to quote the Apocalypses rather than the Synopses, since they've diverged somewhat, and the Synopses are being kept rather more up-to-date. The "post" block has turned into a "leave" block, for instance. (Pre/post blocks are reserved for Design-By-Contract now.) Anyway, I think we'll need to recognize over the long haul that some forms of control flow are simply incompatible with certain kinds of state change, in a Haskellian monadic sense. I think if the first whack at rezipping can simply detect such situations and refuse to proceed, we'll at least be up to the Perl 5 level, even if we can't continue into a temporized area. After all, the entire Perl 5 model assumes that you only have to undo once. It'd be nice to generalize from that, but Perl 6 is moving more toward using a thing we're calling "environmental" lexical variables to represent dynamic context anyway, which I think is more like what you'd call a deep binding. So from a Perl perspective, temporization is being de-emphasized somewhat. On the other hand, as you point out, you do have to be careful about unwinding exceptions. We'll need to do that as lazily as possible, since some exceptions will include an optional continuation to resume if the exception thrower wants to allow the exception to be "defatalized". In fact, I suspect we'll end up handling all warnings as exceptions that are defatalized by default by an outermost warning exception handler, and it'd be a shame if, when we resume after a warning, the temporizations have all been undone. Even if they get rezipped at resumption, that's gotta be a big performance hit just to emit a warning. So maybe there's some way of running CATCH blocks in the dynamic context of the thrower without rezipping twice. Have to think about the semantic ramifications of that though... Larry
