Re: define and set! with multiple-values

[dyer@eagle.sharebase.com (Scot Dyer)]

From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
///     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.

This is true when it is not apparent from the CALL that the function will
return multiple values.  A special form (like BIND) can solve this problem.

///     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.
///
/// [...stuff deleted...]
///
/// 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.

Conceivably, the fabled "sufficiently smart compiler" should be able to
tell from the call how many of the values will be used, and not compute
the others in most cases where the (values...) form is actually part of
the function definition, yes?

Maybe we need to look at this sideways -- what if a function called in
the usual way returned only the one value, but a function in some
special form -- call it 'squeeze'* -- can arrange to bind extra
values...  Actually, this is just some alternate calling convention to
say that multiple values are requested.  I suppose the current Dylan
BIND form is sufficient for this, but personally, I'd like these extra
values to be named rather than numbered.  I think this is reasonable,
as is Scott's request for a special bind form.  Imagine sqeezing 'floor' for
'fractional-part:'...

Also, there's an issue of code maintainability -- what if a new implementation
for some function F allows me to return more information?  Do I _dare_ add this
information, possibly flubbing up callers?  Do I simply _append_ this as one
additional (un-named) item to be returned?  (Everyone's seen at least one
function whose readability has permentantly been lost to MV -- usually when
playing with it themselves for the first time...)

I don't want to spell out an actual syntax for this proposal, since I
don't want to narrow it unnecissarily, and it's too early for me to
think [on a monday].

+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh    | "Land of song," said the warrior bard,	 |
|dyer@eagle.sharebase.com| "Though all the world betrays thee,		 |
+------------------------+  One sword, at least, thy rights shall guard, |
|(He's right, you know.) |  One faithful harp shall praise thee."	 |
+------------------------+-----------------------------------------------+

* or EXTENDED-CALL, or what have you.  It should have an APPLY equiv., too.
  Damage = 2 new identifiers... Ouch!