Pascal Costanza wrote:
> Hi folks,
>
> I have written the following macro.
>
...snip...
>
> Its purpose is to allow returning values from somewhere in the middle of
> a function.
Well, prog1 was my first thought, but then I see you aspire to:
(defun rodney ()
(yada-yada 4 5 6)
(+ 1 @(the-calculation-rodney-returns 2) 3)
(and-so-on 'a 'b 'c))
So my second thought is, how does the value meant to be returned by a
function get so little respect within said function?
prog1 does not bother me because yer kinda doing GF-ian :after processing:
(defun rodney (thing)
(yada-yada 4 5 6)
(prog1
(the-calculation-rodney-returns thing)
(mop-up-destructively thing)))
But in the first example the form whose value you
want to return is buried within some /other/ interesting form,
too far from the toplevel of the function to be progn'ed out.
So there is all this other stuff going on and the function's return
value (which strikes me as something pretty important to a function) is
just some form you happened to get to while doing /surrounding/ stuff
involving that form. Words fail me. it's like having a bit actor in a
stage play come out last to take a bow.
Lawdy, how often does this come up? I'd forget ····@ and think about
refactoring. Mind you, I am way out on a limb here because I do not
know what you are up to over there.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
> Lawdy, how often does this come up? I'd forget ····@ and think about
> refactoring. Mind you, I am way out on a limb here because I do not
> know what you are up to over there.
Thanks for your comments. Well, I have seen the following idiom.
(defmethod m :around (...)
(multiple-value-prog1
(progn
(...)
(call-next-method))
(...)))
I find this rather ugly. So what I want to have is something like that.
(defmethod m :around (...)
(····@
(...)
@(call-next-method)
(...)))
I think this is somewhat nicer. However, you have to admit that this
calls for generalization. ;-)
Please note that I am still in a kind of learning mode and this is
partly just for the fun of seeing if I have gotten things right. (Yeah,
I know, very selfish... ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>> Lawdy, how often does this come up? ...
>
>
> Thanks for your comments. Well, I have seen the following idiom.
>
> (defmethod m :around (...)
> (multiple-value-prog1
> (progn
> (...)
> (call-next-method))
> (...)))
Yes, we have one of those somewhere in our app. It's a big app, tho. :)
And like I said, that just means we have both before and after
processing around the meat of the function, nothing wrong with that (in
rare cases) except some visual confusion.
otoh, (+ 1 return-me 3) cries out for refactoring.
> Please note that I am still in a kind of learning mode and this is
> partly just for the fun of seeing if I have gotten things right.
I did wonder if that was part of the motivation, and a fine motivation
it is. Hopefully, tho, like Nixon you will conclude "We could do it, but
it would be wrong."
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
* Pascal Costanza <········@web.de>
| Thanks for your comments. Well, I have seen the following idiom.
|
| (defmethod m :around (...)
| (multiple-value-prog1
| (progn
| (...)
| (call-next-method))
| (...)))
|
| I find this rather ugly. So what I want to have is something like that.
|
| (defmethod m :around (...)
| (····@
| (...)
| @(call-next-method)
| (...)))
|
| I think this is somewhat nicer. However, you have to admit that this calls
| for generalization. ;-)
(defmethod m :around (...)
(...)
(multiple-value-prog1
(call-next-method)
(...)))
I fail to see the problem. Elsewhere, a simple `let� form that captures
the value and returning is value at the end seems to do a much better job
at this:
(...)
(let (($ ...))
(... $ ...)
$)
If your value has no natural name, using a symbol like $ should be OK,
but you should really think of a good name for the value if it is used
elsewhere in the function.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Pascal Costanza <········@web.de> writes:
> Kenny Tilton wrote:
>
> > Lawdy, how often does this come up? I'd forget ····@ and think about
> > refactoring. Mind you, I am way out on a limb here because I do not
> > know what you are up to over there.
>
> Thanks for your comments. Well, I have seen the following idiom.
>
> (defmethod m :around (...)
> (multiple-value-prog1
> (progn
> (...)
> (call-next-method))
> (...)))
>
> I find this rather ugly. So what I want to have is something like that.
>
> (defmethod m :around (...)
> (····@
> (...)
> @(call-next-method)
> (...)))
>
> I think this is somewhat nicer. However, you have to admit that this
> calls for generalization. ;-)
>
>
> Please note that I am still in a kind of learning mode and this is
> partly just for the fun of seeing if I have gotten things
> right. (Yeah, I know, very selfish... ;)
You might also want to consider efficiency issues. Calls to
multiple-value-list are likely to cons, whereas performing the
above with :before and :after methods are more likely to be
done cons-free.
Also, although call-next-method is a powerful tool, it tends also to
be harder to optimize in effective-methods than straight :before and
:after methods.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182