On Sun, Jan 21, 2001 at 02:06:39PM +0000, Alan Burlison wrote: > Nicholas Clark wrote: > > > This makes sense. I'm reasoning (well, guessing) that eval really needs > > interpreter data structures that let us make a proposed set of changes, > > and then roll back or commit them when the eval exits > > (can any relational database nest transactions? if not, then perl has do to > > something more than they do) > > I'm leery of this idea of putting transactions into perl. There was a Hangon. Is this perl6 now? Which list should it get to? I was meaning it more as an analogy, for stuff that shouldn't leak if an eval dies. But it's not a great one, as you can eval inside an eval. And only perl internals stuff. I was meaning that this was "implementation" and perl scripts don't get to see it. > side. Please, let's get something a) well architected b) simple and c) > robust working first before we start trying to do a PhD project. I agree. And I don't think we ever want to do a PhD project. We'd like something that works for applications. Not research exploring the alternatives available. Nicholas ClarkThread Previous | Thread Next