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.
_______________________________________________
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
