[alexandria-devel] [PATCH] PROG1-LET

[Benjamin Saunders]

On Tue, Apr 10, 2012 at 10:13:33AM +0300, Nikodemus Siivola wrote:
> WHEN-LET and IF-LET have a fairly common use-case ... where in a
> typical case the /relative/ reduction in lines of code is a
> substantial 33% -- and they are also "classic": been around forever,
> re-invented independently by several people. 

Though I'm no judge of classicality, judging from the response on this
list the anaphoric form, aprog1, is fairly well known and used. It
certainly isn't much shorter than the obvious approach with let, but I
find it to be clearer to read: while let is often used for
intermediate values of only local interest, prog1 clearly expresses
that the value in question is to be returned by the form, without
requiring that every possible codepath within the form be considered.

> For the single-binding case there is also little chance of "guessing
> wrong" what it actually does. In case of PROG1-LET, I actually
> assumed...

This surprises me. WHEN-LET and IF-LET establish a pattern of "bind a
value and pass it as the first argument of the corresponding form,"
which generalizes directly to my implementation of PROG1-LET. On this
basis I had assumed that the expansion was so obvious as to barely
merit explanation beyond that implied by the name itself.

> in particular because I would write that as just a LET, without
> using PROG1 at all

Perhaps my assumptions are skewed due to my familiarity with this
pattern's nearly equivalent incarnation in aprog1, which I have used
to the same end in the past, but I don't seem to be unusual in that
regard.

> A "bind values, do stuff, return the bindings" -macro similar
> PROG1-LET would IMO fit fine in Alexandria, but PROG1-LET is not a
> good name for it.

I'm glad to hear you approve of the general idea. I'm certainly not
attached to the name--the entire PROG class of names has always struck
me as a gratuitously non-obvious throwback--and only named it in that
manner for consistency and assumed obviousness-of-function in the
presence of the existing binding macros. Given that I seem to have
overestimated this effect, that rationale breaks down. I have named
similar abstractions 'returning' in the past, though 'returning-let'
seems a bit unwieldly. Do any superior names occur to you?

> I also suspect it only gains true utility if it returns multiple
> values, but then we're back at looking for use-cases...

As previously mentioned, I find this macro useful primarily not to
make code more concise, but more obvious of meaning, and feel that its
existence is adequately justified by that alone. That said, it would
hardly be impaired by returning multiple values and thereby reducing
boilerplate in the (perhaps uncommon) use-case of a binding
multiple-value-prog1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/alexandria-devel/attachments/20120410/efda9983/attachment.sig>