[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[srfi-11] LET-VALUES wrapup (was: Re: Another vote for more parens)

(Sorry for dropping this on the floor for 6 weeks, I guess we should
thank the editors for not vigilantly moving SRFIs to "final" status
when the draft period is up! ;)

Open issues:

  (a) Leave it alone, or add a level of parens to allow multiple sets of
      bindings.  In favor: me.
		 Against: Hilsdale, Sperber(?), and the MzScheme/DrScheme/... 
                 suite of programs.  Probably most everyone else, too.

  (b) If we're adding parens, do we need to introduce LET-VALUES*,

As to (a), Erik Hilsdale writes:

>Whenever I use let-values, I always write it as
>  (let-values ((Formals Exp) ...) Exp ... Exp)
>rather than this SRFI's
>  (let-values (Formals Exp) Exp ... Exp)
>I do understand that the extra parens are annoying when there's only
>one binding, which is why I frequently use one of two other forms when
>I only care to use one binding.  When I'm thinking about monads I tend
>to use 
>  (bind (Formals Exp) Exp ... Exp)
>which works just as this SRFI's version.  In most of my usual coding I
>  (with-values Exp Consumer) ; Consumer should evaluate to a procedure
>because (a) I'm pretty used to cps, (b) it's an extremely short macro,
>and (c) it only uses a trifle (two spaces) more horizontal space than

In response I can only say that I rarely think about monads and that if
I wanted to use CPS I would be fairly happy with CALL-WITH-VALUES... :-/

Looking at both my code and code written by others, the use of
LET-VALUES and CALL-WITH-VALUES varies, and clearly there are cases when
multiple bindings of multiple values are created.  This is a point in
favor of using an extra nesting level.

As to (b), adding LET-VALUES* or LET*-VALUES make sense.  LETREC-VALUES
strikes me as fairly absurd; I can see no use for it.  I see MzScheme
supports it, but it is not used even once in over 42,000 lines of Scheme
source in the MzScheme distribution.

So, proposal:  I change the spec for LET-VALUES to require the extra
level of nesting, thus facilitating

	(let-values (((a b) e1)
		     ((c d) e1))

but also allowing syntax of the form

	(let-values ((l e1)           ; grab all results into l
		     ((a b . l) e2))  ; grab two results and rest into l

and introducing a compatible LET*-VALUES form (MzScheme's name for it).


[ Mike, please hold off on finalization until the dust has settled. ]