[pro] BOA constructor and supplied-p argument

[Pascal Costanza]

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20110612/287a64f9/attachment.html>