[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: define and set! with multiple-values I think I've changed my mind.
- To: firstname.lastname@example.org
- Subject: Re: define and set! with multiple-values I think I've changed my mind.
- From: email@example.com (Ben A. Hyde)
- Date: Mon, 4 Jan 93 10:47:38 EST
As far as I know it is not possible to implement safe
multiple values with out requiring many functions also set a value
(defun foo (x)
(+ x x))
must set the value count to as well as do the tiny bit of work
required to do the addition. Meanwhile
(defun bar (x)
doesn't have to set it.
Notice this is the worse kind of purity v.s. efficiency trade off.
We are taxing most functions for a cost that benefits only a
very few functions. Second, this cost can not be eliminated by a
compiler switch that proclaims that we want to run unsafe.
Such an "unsafe" switch would presumably just ignore the multiple
value count neither setting or checking it. That doesn't work out
since one of the principle uses of the multiple values is to return an
exceptional additional value. For example a flag indicating that the
first value is suspect...
(defun do-next ()
(multiple-value-bind (score suspect?) (get-value)
(incf total-score score)
The call tree below get-value may have a hundreds of individual
functions that compute get-value's return. Maybe 20% of them return the
suspect? flag. A compiler switch that ignores the value count is
useless on code like this.
Just how bad is the cost of this one additional instruction to set the
return value? Well that depends on your intuitions about the size
distribution of functions.
In the system I'm currently working on we have tremendous numbers of
tiny little functions that are created by macros, so lexically they
are extremely common so this extra instruction effects my over all
In this same system we do a tremendous about of indirect function
calling and most of those functions return no values. In many cases
the performance tuning bottoms out in places where we scan a data
structure calling a series of functions indirectly and many of those
functions do a very tiny bit of work. The cost of a small function
call becomes critical at that point.
I like multiple return values. I find them elegant and pleasant to
use. In systems I've built we have used them with great satisfaction.
It would be very sad to see them removed from Dylan, but I would be
more likely to adopt Dylan if it didn't have multiple return values.
- Ben Hyde