On 11 Jun 2011, at 21:25, Daniel Weinreb wrote:

I don't like (let (a b c) ...) any more than I do &aux. I suppose it's because I'm trying to think "functionally", with "let" as much as possible being "compute this value and give it a name" rather than "declare this variable so I can start side-effecting it.

In general, I agree about (let (a b c) ...), but there are situations where it's hard to avoid.

I wish there were an idiomatic way to have a let where the variable cannot be set later. I do have a macro for this in our library, but I don't use it since it's not part of our general programming style and consistency of style is so important.

There is, actually: (flet ((a () 5)) ;; now (a) can only be read, but not assigned to ...) 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: (flet ((a () 5)) (symbol-macrolet ((a (a))) ...))

I'm not saying there's no place for let followed by side effects. It's just not the way I usually think of it.

Right.

Also, putting things in the parameter list that aren't parameters just feels weird.

...but they are parameters, just not parameters passed by the client code explicitly. ;)

If I were designing Lisp again, I would also consider not having &rest at all, and instead pass in "maps", i.e. like alists, so that it would be easier to pass on these arguments to other functions without having to deal with "apply".

A lot of the original motivation of &rest was to avoid consing. In the original implementation, the list values of &rest parameters were stack-consed, and you were supposed to be careful not to retain them beyond the scope of the function, a trap for the unwary, which could have very bad consequences.

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. 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.

And I would get rid of the supplied-p business, which REALLY makes it hard to pass values on to other functions. Function composition should not be hard to do.

Agreed.

But it's way to late to redesign Common Lisp.

No need to be pessimistic. We're still way ahead of everybody else. ;) Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.