I recently heard about an interesting technique for writing
initialization code. A common problem in initialization is that if
there is a failure then the program should stop and come back to a
previous state before initialization began. Partial initialization
isn't valid. Any resource allocated in the initialization must
deallocated if there is a failure.
In lisp this isn't a problem for allocation of memory, but can be for
other things. For example if two files are opened to perform an
action, then both must be closed regardless of whether the action
succeeds or not. This is easy using with-open-file.
There are other situations like the above where resources are allocated
and their allocation later undone that are more complicated. In the
case of files the file handling code (ie with-open-file) can know how
to undo the relevant action. In some cases though the action
to be undone may have nothing obvious to do with the error encountered.
An example given in the article mentioned below is of a system that
stores data about users in both memory and in a database. If either of
them fails then they throw an exception. F.e.g. :-
(defun user-add-friend (new-friend)
"Add a friend to an existing user"
(push new-friend friends) ;; Add to list
(handler-case
(database-add-friend user-name new-friend-name)
(database-addition-error () (pop friends))))
This kind of stuff works fine, so long as there aren't too many
resources captured and released. If there are a lot though then deeply
nested handler-case/catch statements are needed. This can be hard to
follow.
In C++ something called ScopeGuard has been invented to do this, see:
http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm .
For each action the programmer defines an undo action, then if an error
occurs then the relevant undo actions are executed. In C++ this is done
with some odd uses of templating and auto_ptr I don't fully understand.
The fundamental trick to it though is that destructors for an object
are executed when the object falls out of scope.
In lisp something similar can be done, you could write a macro like
this ...
(blocks-with-undos
BLOCK
UNDO
BLOCK
UNDO ...)
Where each "block" and "undo" is a progn.
If an error occurs within blocks-with-undos, then all the relevant undo
actions are executed and state returned to how it was before the block
started. Code can be added around this to catch the error(s) and
report them. It could even be modified to deal with functions that
return errors rather than throwing exceptions.
The macro can sort the code back into it's normal form using
conditions. I've written a macro that can do this, I'll post it if
anyone is interested.
I don't think that it is the best solution though. In C++ Scopeguard
you can write code like this:-
void User::AddFriend(User& newFriend)
{
friends_.push_back(&newFriend); // Add user
ScopeGuard guard = MakeObjGuard( // register pop_back as undo
friends_, &UserCont::pop_back);
pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
guard.Dismiss(); // dismiss undo
}
That is the undo code and guarded code can be written as normal code.
The code does not have to be structured in any particular way as it
does with my blocks-with-undos above. The capability to add undos to
actions is available everywhere.
My question is: Is it possible to do the same thing with lisp, and if
so how?
And, is it a useful thing to do or are there reasons to avoid it?
Rob Thorpe wrote:
> I don't think that it is the best solution though. In C++ Scopeguard
> you can write code like this:-
>
> void User::AddFriend(User& newFriend)
> {
> friends_.push_back(&newFriend); // Add user
> ScopeGuard guard = MakeObjGuard( // register pop_back as undo
> friends_, &UserCont::pop_back);
> pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
> guard.Dismiss(); // dismiss undo
> }
>
> That is the undo code and guarded code can be written as normal code.
> The code does not have to be structured in any particular way as it
> does with my blocks-with-undos above. The capability to add undos to
> actions is available everywhere.
>
> My question is: Is it possible to do the same thing with lisp, and if
> so how?
Do you mean something like this?
(defvar *current-guard*)
(defmacro with-guard (guard &body body)
`(let ((*current-guard* (lambda () ,guard)))
(handler-case (progn ,@body)
(error (e)
(funcall *current-guard*)
(error e)))))
(defparameter *friends* '())
(defun add-to-database (object)
(when (> (random 2) 0)
(error "Sorry, no way!")))
(defun test ()
(push "Dilbert" *friends*)
(with-guard
(pop *friends*)
(add-to-database "Dilbert")))
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Rob Thorpe wrote:
>
> > I don't think that it is the best solution though. In C++ Scopeguard
> > you can write code like this:-
> >
> > void User::AddFriend(User& newFriend)
> > {
> > friends_.push_back(&newFriend); // Add user
> > ScopeGuard guard = MakeObjGuard( // register pop_back as undo
> > friends_, &UserCont::pop_back);
> > pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
> > guard.Dismiss(); // dismiss undo
> > }
> >
> > That is the undo code and guarded code can be written as normal code.
> > The code does not have to be structured in any particular way as it
> > does with my blocks-with-undos above. The capability to add undos to
> > actions is available everywhere.
> >
> > My question is: Is it possible to do the same thing with lisp, and if
> > so how?
>
> Do you mean something like this?
>
> (defvar *current-guard*)
>
> (defmacro with-guard (guard &body body)
> `(let ((*current-guard* (lambda () ,guard)))
> (handler-case (progn ,@body)
> (error (e)
> (funcall *current-guard*)
> (error e)))))
>
> (defparameter *friends* '())
>
> (defun add-to-database (object)
> (when (> (random 2) 0)
> (error "Sorry, no way!")))
>
> (defun test ()
> (push "Dilbert" *friends*)
> (with-guard
> (pop *friends*)
> (add-to-database "Dilbert")))
No, not really. What I was looking for was a way to avoid having to
contain code in many dynamic scopes.
If a lot of resources need to be allocated as above, instead of just
two, then each needs a with block and more indentation. What I was
looking for was a way to avoid this.
C++ programmers have found a way, but I think that's mainly because
most of them treat memory the same way as other resources and
deallocate it manually or at the end of scopes. So the nesting problem
becomes bigger for them.
I'm interested because I may soon have to write a bit of software to
manipulate a set of physical devices, each of which will be some kind
of resource inside the software.
(I know you can attach other stuff to the GC and therefore have other
resources than memory GCed, but that's nasty because the GC is not
gauranteed to deallocate anything).
Rob Thorpe wrote:
> Pascal Costanza wrote:
>
>>Rob Thorpe wrote:
>>
>>
>>>I don't think that it is the best solution though. In C++ Scopeguard
>>>you can write code like this:-
>>>
>>>void User::AddFriend(User& newFriend)
>>>{
>>> friends_.push_back(&newFriend); // Add user
>>> ScopeGuard guard = MakeObjGuard( // register pop_back as undo
>>> friends_, &UserCont::pop_back);
>>> pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
>>> guard.Dismiss(); // dismiss undo
>>>}
>>>
>>>That is the undo code and guarded code can be written as normal code.
Jeez, that is not normal code, you have the error handling boilerplate
all over the place in the middle of the normal code. Or maybe I mean,
yeah, that is normal code, but that is a bug, not a feature, having the
error-handling code swimming around with the code you want to safeguard.
>>>The code does not have to be structured in any particular way as it
>>>does with my blocks-with-undos above.
Yeah, I think it does. Your guard is dismissed as soon as AddFriend
completes (if I am following the C++ and the name "dismiss"). You said
you had all sorts of initializations to do. What if the next fails? Your
guard is not asleep at the post, she has been laid off.
>>> The capability to add undos to
>>>actions is available everywhere.
>>>
>>>My question is: Is it possible to do the same thing with lisp, and if
>>>so how?
>>
>>Do you mean something like this?
>>
>>(defvar *current-guard*)
>>
>>(defmacro with-guard (guard &body body)
>> `(let ((*current-guard* (lambda () ,guard)))
>> (handler-case (progn ,@body)
>> (error (e)
>> (funcall *current-guard*)
>> (error e)))))
>>
>>(defparameter *friends* '())
>>
>>(defun add-to-database (object)
>> (when (> (random 2) 0)
>> (error "Sorry, no way!")))
>>
>>(defun test ()
>> (push "Dilbert" *friends*)
>> (with-guard
>> (pop *friends*)
>> (add-to-database "Dilbert")))
>
>
> No, not really. What I was looking for was a way to avoid having to
> contain code in many dynamic scopes.
Well, I still do not see how you have that in the example you gave in
which you /apparently/ dismiss the guard as soon as the guarded action
completes.
What I would expect was:
clear guard registry
start big long initialization
if that all finishes OK
dismiss all registered guards
else
dispatch all registered guards
end if
I do not know if one can code that in C++, I just think that is the
functional requirement you have specified. Arbitrary code can register
guards along the way and finish their normal task, but guard cleanup has
to weight until some supervisor decides the transaction, if you will, is
complete.
The above is easy i Lisp, and a nifty WITH-GUARD macro and a special
variable can (a) hide a lot of boilerplate and (b) keep it the guarding
code separate from the normal-path code. You can even have nested
transactions if you need that.
I'd say more but your code example has me dubious I understand you.
> (I know you can attach other stuff to the GC and therefore have other
> resources than memory GCed, but that's nasty because the GC is not
> gauranteed to deallocate anything).
>
Yeah, don't do that.
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Ken Tilton wrote:
> Rob Thorpe wrote:
> > Pascal Costanza wrote:
> >>Rob Thorpe wrote:
> >>>I don't think that it is the best solution though. In C++ Scopeguard
> >>>you can write code like this:-
> >>>
<snip>
> >>>
> >>>That is the undo code and guarded code can be written as normal code.
>
> Jeez, that is not normal code, you have the error handling boilerplate
> all over the place in the middle of the normal code. Or maybe I mean,
> yeah, that is normal code, but that is a bug, not a feature, having the
> error-handling code swimming around with the code you want to safeguard.
Unfortunately it's often difficult to write code without a lot of error
handling in it.
> >>>The code does not have to be structured in any particular way as it
> >>>does with my blocks-with-undos above.
>
> Yeah, I think it does. Your guard is dismissed as soon as AddFriend
> completes (if I am following the C++ and the name "dismiss"). You said
> you had all sorts of initializations to do. What if the next fails? Your
> guard is not asleep at the post, she has been laid off.
No, the guard is dismissed only by a dismiss operation. This is a
small example. In a longer example more would be done before the guard
is dismissed. If the scope ends before it is dismissed then the guard
is executed (this is AFAIK unavoidable in the C++ implementation, but
not always helpful).
> >>> The capability to add undos to
> >>>actions is available everywhere.
> >>>
> >>>My question is: Is it possible to do the same thing with lisp, and if
> >>>so how?
> >>
> >>Do you mean something like this?
> >>
> >>(defvar *current-guard*)
> >>
> >>(defmacro with-guard (guard &body body)
> >> `(let ((*current-guard* (lambda () ,guard)))
> >> (handler-case (progn ,@body)
> >> (error (e)
> >> (funcall *current-guard*)
> >> (error e)))))
> >>
> >>(defparameter *friends* '())
> >>
> >>(defun add-to-database (object)
> >> (when (> (random 2) 0)
> >> (error "Sorry, no way!")))
> >>
> >>(defun test ()
> >> (push "Dilbert" *friends*)
> >> (with-guard
> >> (pop *friends*)
> >> (add-to-database "Dilbert")))
That's a bit neater than using handler-case on it's own, but only
allows you to add one guard at a time without lots of indentation.
> > No, not really. What I was looking for was a way to avoid having to
> > contain code in many dynamic scopes.
>
> Well, I still do not see how you have that in the example you gave in
> which you /apparently/ dismiss the guard as soon as the guarded action
> completes.
In the example, two things are done:
The user is added into the memory list:
friends_.push_back(&newFriend); // Add user
There is no problem if an exception occurs here, because the operation
will fail and no further lines of this function will be executed.
Then into the database:
ScopeGuard guard = MakeObjGuard( // register pop_back as undo
friends_, &UserCont::pop_back);
pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
If an error occurs here then the memory list is mended to tally with
the contents of the database. If there were more operations that
required atomicity then they would all be done before issuing
guard.Dismiss();
> What I would expect was:
>
> clear guard registry
> start big long initialization
> if that all finishes OK
> dismiss all registered guards
> else
> dispatch all registered guards
> end if
>
> I do not know if one can code that in C++, I just think that is the
> functional requirement you have specified. Arbitrary code can register
> guards along the way and finish their normal task, but guard cleanup has
> to weight until some supervisor decides the transaction, if you will, is
> complete.
>
> The above is easy i Lisp, and a nifty WITH-GUARD macro and a special
> variable can (a) hide a lot of boilerplate and (b) keep it the guarding
> code separate from the normal-path code. You can even have nested
> transactions if you need that.
The problem is that everything must be nested in some underlying way.
In the pseudo code you mentioned above there is a problem:
If an exception occurs in one part of the initialization it is not
correct to undo all parts of the initialization. For example:-
<open file>
<open lock>
<open pipe> <-- error occurs here
<open database>
In the above, when the pipe fails to open the file should be closed,
the lock unlocked, but the database should *not* be closed.
It's often not a bug to close something which may or may not exist, but
it sometimes is.
I think the macro Pascal mentioned does the business, but I need to
check it.
On 27 Mar 2006 12:47:41 -0800, "Rob Thorpe"
<·············@antenova.com> wrote:
>If a lot of resources need to be allocated as above, instead of just
>two, then each needs a with block and more indentation. What I was
>looking for was a way to avoid this.
Make a with-devices macro and invoke it like this:
(with-devices
((printer ...)
(scanner ...)
(shredder ...))
(print ...)
(scan ...)
(shred ...))
Rob Thorpe wrote:
> No, not really. What I was looking for was a way to avoid having to
> contain code in many dynamic scopes.
So I understand that what you're worried about is not the specifics of
how resource allocation and deallocation (in that concrete C++
framework), but rather the syntax, i.e., reduction of indentation.
I have tried to distill the essence of this, and here is a suggestion:
(defgeneric destruct (destructible))
(defmacro with-destructibles (&body body)
`(let (destructibles)
(flet ((add-destructible (destructible)
(push destructible destructibles))
(delete-destructible (destructible)
(setf destructibles
(delete destructible destructibles))))
(unwind-protect
(progn ,@body)
(mapc #'destruct destructibles)))))
(defclass person ()
((name :initarg :name :accessor name)))
(defmethod destruct ((p person))
(format t "~A feels destructed.~%" (name p)))
(defun test ()
(with-destructibles
(let ((p1 (make-instance 'person :name "Dilbert"))
(p2 (make-instance 'person :name "Dogbert")))
(add-destructible p2)
(add-destructible p1)
(delete-destructible p2))))
I have opted for a lexical variable 'destructibles here instead of a
special variable in order to ensure that code that wants to use this
feature is properly wrapped by 'with-destructibles. I am not 100% sure
if that's really necessary. Wrt macro hygiene, I assume that this code
would end up in its own package, so we don't have to worry about
accidental capture of 'destructibles.
If you don't like the fact that you have to wrap your code in
'with-destructibles, you can shadow 'defun, etc., like this:
(shadow 'defun) ; better do this in an appropriate defpackage form.
(defmacro defun (name (&rest args) &body body)
`(cl:defun ,name ,args
,@(loop for (first . rest) on body
if (or (stringp first)
(and (consp first)
(eq (first first) 'declare)))
collect first into declarations
else return `(,@declarations
(with-destructibles
,first
,@rest))))))
[Warning: untested!]
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Rob Thorpe wrote:
> > No, not really. What I was looking for was a way to avoid having to
> > contain code in many dynamic scopes.
>
> So I understand that what you're worried about is not the specifics of
> how resource allocation and deallocation (in that concrete C++
> framework), but rather the syntax, i.e., reduction of indentation.
>
> I have tried to distill the essence of this, and here is a suggestion:
>
> (defgeneric destruct (destructible))
>
<snip>
> (defun test ()
> (with-destructibles
> (let ((p1 (make-instance 'person :name "Dilbert"))
> (p2 (make-instance 'person :name "Dogbert")))
> (add-destructible p2)
> (add-destructible p1)
> (delete-destructible p2))))
>
>
> I have opted for a lexical variable 'destructibles here instead of a
> special variable in order to ensure that code that wants to use this
> feature is properly wrapped by 'with-destructibles. I am not 100% sure
> if that's really necessary. Wrt macro hygiene, I assume that this code
> would end up in its own package, so we don't have to worry about
> accidental capture of 'destructibles.
>
> If you don't like the fact that you have to wrap your code in
> 'with-destructibles, you can shadow 'defun, etc., like this:
>
> (shadow 'defun) ; better do this in an appropriate defpackage form.
>
> (defmacro defun (name (&rest args) &body body)
<snip>
>)))))
Excellent, that's what I meant. I'll give it a try. Your code actually
looks much simpler than how I thought it would look.
Probably shadowing defun isn't necessary, since "with-destructibles"
takes only one level of indentation.
Pascal Costanza wrote:
> Rob Thorpe wrote:
>
> > No, not really. What I was looking for was a way to avoid having to
> > contain code in many dynamic scopes.
>
> So I understand that what you're worried about is not the specifics of
> how resource allocation and deallocation (in that concrete C++
> framework), but rather the syntax, i.e., reduction of indentation.
>
> I have tried to distill the essence of this, and here is a suggestion:
> [code elided]
Isn't that interesting! I've been doing work with RDNZL lately, and had
to worry about .NET's numerous IDisposable objects, so I came up with a
very similar solution to the one you suggested. I found this easy to
write by writing the singular form first, then the plural form. (I know
this ain't rocket science, but I've only recently started doing
significant amounts of Lisp coding.)
(defmacro with-disposable ((var init) &body body)
"Manages the scope of an IDisposable object."
(assert (symbolp var))
`(let ((,var ,init))
(unwind-protect
(progn ,@body)
(when (and (container-p, var)
(?.IsInstanceOfType (get-type-object
'?System.IDisposable)
,var))
(dispose ,var)))))
(defmacro with-disposables* ((&rest init-forms) &body body)
"Manages the scope of multiple sequentially-created IDisposable
objects."
(assert (consp init-forms))
(let ((first-form (first init-forms))
(rest-forms (rest init-forms)))
(if rest-forms
`(with-disposable ,first-form
(with-disposables* ,rest-forms ,@body))
`(with-disposable ,first-form ,@body))))
(Ignore the funny-looking symbols starting with question marks; they're
interpreted by the reader of the layer I built on top of RDNZL.)
CONTAINER-P is a RDNZL function that makes sure the object is RDNZL
"container", or .NET object. Ignoring non-containers lets me be lax
about using the form to initialize symbols referring to more mundane
data, too.
Of course, the way I wrote it, the macro expansion can end up nesting
very deeply; I don't know if that matters to the OP.
> [Warning: untested!]
I've actually been using mine. :-)
--
Dan Muller
http://spookydistance.com/blogs/danm/
In article <·······················@e56g2000cwe.googlegroups.com>,
"Rob Thorpe" <·············@antenova.com> wrote:
> I don't think that it is the best solution though. In C++ Scopeguard
> you can write code like this:-
>
> void User::AddFriend(User& newFriend)
> {
> friends_.push_back(&newFriend); // Add user
> ScopeGuard guard = MakeObjGuard( // register pop_back as undo
> friends_, &UserCont::pop_back);
> pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
> guard.Dismiss(); // dismiss undo
> }
>
> That is the undo code and guarded code can be written as normal code.
> The code does not have to be structured in any particular way as it
> does with my blocks-with-undos above. The capability to add undos to
> actions is available everywhere.
>
> My question is: Is it possible to do the same thing with lisp, and if
> so how?
>
> And, is it a useful thing to do or are there reasons to avoid it?
Personally I would think in two directions.
a) I would use a Lisp with transactions (say, a relational
Lisp like AP5).
Btw., for those interested in language comparisons,
they may read this classic paper:
http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/haskell-vs-ada-abstract.html
Note the performance of the users of 'Relational Lisp'. ;-)
It is worth for a good laughs, too.
b) I would use CLOS' Generic Functions with a special
Method Combination.
User code might look like this:
(defgeneric do-something-possibly-failing (user registry)
(:method-combination :recoverable))
(defmethod do-something-possibly-failing
((user webserver-user) (registry server-registry))
(do-something user registry))
(defmethod do-something-possibly-failing :save
((user webserver-user) (registry server-registry))
...)
(defmethod do-something-possibly-failing :restore-on-error
((user webserver-user) (registry server-registry))
...)
I would implement the method combination with some
special error handler wrapping the methods.
For some inspiration how to write these method combinations
(beware, this is advanced CLOS) see this
example how to implement an Eiffel-like Design-by-Contract
method combination in Common Lisp:
http://www.gauss.muc.de/tools/dbc/dbc-intro.html
--
http://lispm.dyndns.org/
First of all, you are confusing "initialization" with "resource
acquisition". It is true that in C++ there is a principle known as RAII
("Resource Acquisition Is Initialization"), that advocates using
initialization (constructors) for resource acquisition and destruction
(destructors) for resource release. In fact, the important part about
RAII is resource release using destructors.
Rob Thorpe wrote:
> I recently heard about an interesting technique for writing
> initialization code. A common problem in initialization is that if
> there is a failure then the program should stop and come back to a
> previous state before initialization began. Partial initialization
> isn't valid. Any resource allocated in the initialization must
> deallocated if there is a failure.
>
This is not always possible. You are talking about a transaction style
of programming, and more specifically, you are talking about strong
exception (or error) safety. Sometimes, you cannot achieve strong
exception safety, and then you just have to back off to basic exception
safety (avoiding resource leaks, maintaining a valid program state).
> In lisp this isn't a problem for allocation of memory, but can be for
> other things. For example if two files are opened to perform an
> action, then both must be closed regardless of whether the action
> succeeds or not. This is easy using with-open-file.
>
Correct. C++ has deterministic destruction that can be relied upon.
Common Lisp has macros to rely upon. Many other languages don't have
something like that. That problem manifests itself in these languages as
either ugly, repetitive, verbose code, or incorrect code, or both.
An interesting point is that in C++, a destructor should never fail (it
shouldn't exit with an exception). It can ignore the error, log it,
abort the program, call a function, whatever. If you want to detect the
error and act upon it, however, you have to be explicit about it (e.g.,
closing the file without relying on the destructor). In Common Lisp, you
don't have this problem; a macro can act upon the error in any way it
sees fit, including propagation.
> There are other situations like the above where resources are allocated
> and their allocation later undone that are more complicated. In the
> case of files the file handling code (ie with-open-file) can know how
> to undo the relevant action. In some cases though the action
> to be undone may have nothing obvious to do with the error encountered.
> An example given in the article mentioned below is of a system that
> stores data about users in both memory and in a database. If either of
> them fails then they throw an exception. F.e.g. :-
>
> (defun user-add-friend (new-friend)
> "Add a friend to an existing user"
> (push new-friend friends) ;; Add to list
> (handler-case
> (database-add-friend user-name new-friend-name)
> (database-addition-error () (pop friends))))
>
> This kind of stuff works fine, so long as there aren't too many
> resources captured and released. If there are a lot though then deeply
> nested handler-case/catch statements are needed. This can be hard to
> follow.
>
So write a macro. Pascal Costanza's suggestion is a good one. I don't
see how you should suffer from excessive indentation; functions should
be short and do one thing. You could always avoid indentation by writing
a top-level macro and using special syntax (e.g., something like loop),
but I don't see a good reason for this here. In fact, I think
indentation here is a good thing, see below.
Pascal's suggestion is incomplete, though. It assumes too much about
dismissal of a guard. In some cases, you'd want to explicitly dismiss a
guard at a certain point (and sometimes not).
> In C++ something called ScopeGuard has been invented to do this, see:
> http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm .
> For each action the programmer defines an undo action, then if an error
> occurs then the relevant undo actions are executed. In C++ this is done
> with some odd uses of templating and auto_ptr I don't fully understand.
> The fundamental trick to it though is that destructors for an object
> are executed when the object falls out of scope.
>
There's no direct relation to std::auto_ptr. There are simpler
implementations of ScopeGuard that rely on Boost.Bind usage.
> In lisp something similar can be done, you could write a macro like
> this ...
>
> (blocks-with-undos
> BLOCK
> UNDO
> BLOCK
> UNDO ...)
> Where each "block" and "undo" is a progn.
>
> If an error occurs within blocks-with-undos, then all the relevant undo
> actions are executed and state returned to how it was before the block
> started. Code can be added around this to catch the error(s) and
> report them. It could even be modified to deal with functions that
> return errors rather than throwing exceptions.
>
> The macro can sort the code back into it's normal form using
> conditions. I've written a macro that can do this, I'll post it if
> anyone is interested.
>
> I don't think that it is the best solution though. In C++ Scopeguard
> you can write code like this:-
>
> void User::AddFriend(User& newFriend)
> {
> friends_.push_back(&newFriend); // Add user
> ScopeGuard guard = MakeObjGuard( // register pop_back as undo
> friends_, &UserCont::pop_back);
> pDB_->AddFriend(GetName(), newFriend.GetName()); // Add to database
> guard.Dismiss(); // dismiss undo
> }
>
(defmethod add-friend ((me user) (friend user))
(push friend (friends-of me))
(guard-bind guard (pop (friends-of me))
(database-add-friend (database-of me) (name-of me) (name-of friend))
(dismiss guard)))
Note that guard-bind binds a single guard; it's not very often you want
to bind several guards immediately one after the other.
> That is the undo code and guarded code can be written as normal code.
> The code does not have to be structured in any particular way as it
> does with my blocks-with-undos above. The capability to add undos to
> actions is available everywhere.
>
When you create guards is important. In C++, you can't rely on
indentation (or structure) to give you hints about that. This is a good
point for Common Lisp.
> My question is: Is it possible to do the same thing with lisp, and if
> so how?
>
It is possible, and Pascal Costanza's solution is not a bad start.
> And, is it a useful thing to do or are there reasons to avoid it?
>
It is useful when you want transactional kind of safety.
Regards,
Ariel.