<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 11 Jun 2011, at 21:25, Daniel Weinreb wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>I don't like (let (a b c) ...) any more than I do &aux. I suppose</div><div>it's because I'm trying to think "functionally", with "let"</div><div>as much as possible being "compute this value</div><div>and give it a name" rather than "declare this</div><div>variable so I can start side-effecting it.</div></div></blockquote><div><br></div><div>In general, I agree about (let (a b c) ...), but there are situations where it's hard to avoid.</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>I wish there were an idiomatic way to have a let</div><div>where the variable cannot be set later. I do</div><div>have a macro for this in our library, but I</div><div>don't use it since it's not part of our general</div><div>programming style and consistency of</div><div>style is so important.</div></div></blockquote><div><br></div><div>There is, actually:</div><div><br></div><div>(flet ((a () 5))</div><div> ;; now (a) can only be read, but not assigned to</div><div> ...)</div><div><br></div><div>I don't think this is as bad as it may seem at first sight, especially making this look like a variable again is easy:</div><div><br></div><div>(flet ((a () 5))</div><div> (symbol-macrolet ((a (a)))</div><div> ...))</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>I'm not saying there's no place for let followed</div><div>by side effects. It's just not the way I usually</div><div>think of it.</div></div></blockquote><div><br></div><div>Right.</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>Also, putting things in the parameter list that aren't</div><div>parameters just feels weird.</div></div></blockquote><div><br></div><div>...but they are parameters, just not parameters passed by the client code explicitly. ;)</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>If I were designing Lisp again, I would also consider</div><div>not having &rest at all, and instead pass in "maps",</div><div>i.e. like alists, so that it would be easier to pass on</div><div>these arguments to other functions without</div><div>having to deal with "apply".</div><div><br></div><div>A lot of the original motivation of &rest was to</div><div>avoid consing. In the original implementation,</div><div>the list values of &rest parameters were</div><div>stack-consed, and you were supposed to</div><div>be careful not to retain them beyond the</div><div>scope of the function, a trap for the unwary,</div><div>which could have very bad consequences.</div></div></blockquote><div><br></div><div>The fact that &rest can avoid consing is a major win in performance-critical code. Any alternative design that doesn't support this in some way can lead to problems here.</div><div><br></div><div>I'm a bit less happy by now about the separation of required arguments and keyword arguments. Python makes the use of keywords optional for the same arguments, and I think that's actually better. I think this can in principle be implemented very efficiently.</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>And I would get rid of the supplied-p business,</div><div>which REALLY makes it hard to pass values</div><div>on to other functions. Function composition</div><div>should not be hard to do.</div></div></blockquote><div><br></div><div>Agreed.</div><br><blockquote type="cite"><div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>But it's way to late to redesign Common Lisp.</div></div></blockquote><div><br></div><div>No need to be pessimistic. We're still way ahead of everybody else. ;)</div><div><br></div><div>Pascal</div></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>--</div><div>Pascal Costanza</div><div>The views expressed in this email are my own, and not those of my employer.</div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>