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