[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: define and set! with multiple-values
- To: Bob Kerns <rwk@WORLD.STD.COM>
- Subject: Re: define and set! with multiple-values
- From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
- Date: Fri, 01 Jan 93 14:20:29 EST
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Thu, 31 Dec 92 21:28:20 -0500. <199301010228.AA09136@world.std.com>
In my experience, they're not that much work for implementors.
I guess it depends on how hard you want to try to squeeze out that last
cycle or two of per-call overhead. Implementing CL-style multiple-value
returns with *no* added cost to calls/returns that expect/return a single
value is difficult.
However, the single most annoying fault of C (besides syntax)
is the lack of multiple values.
I wouldn't have put this even in the top ten. In any case, this is made
much worse in C by the lack of built-in, efficient dynamic storage
management. In Lisp and Dylan, there is at least the alternative option of
creating and returning a sequence.
If the majority of CL programmers you talk do don't like
multiple-values, I have to suspect that they're mostly
your students, and you're getting a biased sample. Because
that doesn't square with my experience at all.
Well, most are implementors who are influenced by their awareness of what's
going on inside. And some are long-time Lispers who liked the conceptual
simplicity of pre-Common Lisps in which functions always return one value.
I don't have the statistics handy, and it may have changed over the years
as people got used to MV, but I believe that the fraction of calls in which
multiple values are returned and actually used by the caller is well below
1%. So if this were the only consideration, I'd be inclined to say that we
should just return a sequence in those rare cases and count on good GC
technology to make that not too expensive. that way, the 99+% case incurs
no overhead at all, and the language users have one less complication to
There is another problem, however. Maybe 10% of the functions *could*
return additional values that might be of interest to some of their
callers. (I'm thinking of something like FLOOR in Common Lisp.) It's
wasteful to discard these values, because the callers who do want them would
then have to make a second call to get the extra values. It's wasteful to
return all the values in a sequence, because this makes extra work for the
majority of callers who want just the first value. And it's wasteful of
space to have two versions of the function around, one returning single
values and one multiple.
So perhaps something like the current MV system in the Dylan book is the
best compromise after all. I agree that we need improved declaration
facilities for return values, and that topic is being discussed.
Personally, I'd like a separate MV-BIND form to make it visually obvious
that multiple values are being accepted. (Visually obvious to people, that
is -- compilers will have no trouble telling the MV syntax from the
single-value syntax by counting how many items live within each paren.)
I'm still not convinced that we need multiple values in SET! and DEFINE,
but I'm not violently opposed to this.
Scott E. Fahlman Internet: email@example.com
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213