Re: Distinguishing `consp` and `functionp`

[Stefan Monnier]

>> I've been annoyed at the use of lists to represent function values for
>> a while now.
> Why?  Lists are the natural representation, and traditional in Lisp.
> They bring all sorts of advantages (like being able to manipulate code
> easily in Lisp).

Not sure how that relates.  When the code is byte-compiled we already
can't access the function as a plain list.  And when it's native
compiled, we literally can't access its internals from Lisp. at all.

> Blunder?  Having (closure ...) alongside (lambda ...) is an
> inconvenience, yes, but ...  Why a "blunder"?

Because we could have easily used #[closure ...] instead and the problem
would be mostly solved by now :-)

> Please don't do that.  If you must invent a new form, then invent a new
> symbol to signify it.  Misusing #[...] will lead to problems and extra
> work for everybody (as, for example, using the doc string field in
> oclosures for something else has led to extra work).

Actually, if you look at the patch, you'll see that the change tends to
reduces the amount of work that's needed elsewhere because docstrings
and interactive-forms are now found at the same place for interpreted
and (byte-)compiled functions.

> Any packages out there that deal with the internal format of Lisp code
> will be severely affected.

Don't know about "severely", but yes they may be affected.  There really
aren't vry many of them, tho.

> For example, my amendments for bug #67455 (Putting position information
> into doc strings) are already difficult enough.

I'll gladly take care of making the necessary adjustements.

> This change would add a whole new layer of indirection into bug
> #67455's changes.

I don't see how/why.  In the worst case, it will replace one special
case with another.


        Stefan