<div class="gmail_quote">On Fri, May 4, 2012 at 4:37 PM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div>20 minutes ago, Carl Eastlund wrote:<br> ><br> </div>In case it wasn't clear enough, I said that I don't mind having it<br> (and I'm willing to add it) -- I only added that I don't see any<br> *practical* case where you'd use it.<br><div></div></blockquote><div><br></div>Okay, then I think we're more or less on the same page.<br><br>I do think there is a practical use for such a form; specifically, macros that expand into a use of match. Here's a simple example:<br> <br>(define-syntax (let/list stx)<br> (syntax-parse stx<br> [(_ {[(lhs:id ...) rhs:expr] ...} body:expr ...+)<br> (syntax<br> (match (list rhs ...)<br> [(list (list lhs ...) ...) body ...]))]))<br><br> This is a straightforward use of match to destructure a list, but it isn't transparent: it exposes to clients of let/list that _, ..., and any hypothetical match id expanders are invalid choices for lhs. There's no real reason clients of let/list should know that match is even involved. There are existing solutions -- don't use match in macros, or always bind an extra set of temporaries -- but adding some kind of "no really, bind this please" form would be even simpler. I'd call it (var <name>) by analogy to syntax-parse's (~var <name> [<optional-class>]), which I have in fact used for the same purpose.<br> <br>--Carl<br></div>