Re: Distinguishing `consp` and `functionp`

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jan 27, 2024 at 09:25:10 -0500, Stefan Monnier wrote:
> >> 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.

Evasive non-answer number 1.  We're not talking about byte or native
compiled forms.  We're talking about interpreted forms.  The advantages
of Lisp forms had to be foregone in the compiled forms to optimise
performance.  But when being able to manipulate forms is more important
than speed, then the interpreted forms are used.  Your plan will make
this more difficult.

Let me repeat, lists are the natural, traditional representation in
Lisp, which bring all sorts of advantages.  Your proposal will reduce
these advantages.  For what gain?

> > 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 :-)

Evasive non-answer number 2.  What is the advantage of #[closure ...]
over (closure ...)?  I can see only disadvantages.

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

Evasive non-answer number 3.  Where in the new structure you put the
components is independent of the symbol you use.  My point wasn't about
the patch as a whole, it was about the symbol to be used for your new
form.  If you press ahead with this abuse of #[...] it means that every
time somebody wants to check for a byte compiled form, they'll
additionally have to check its innards.  #[ ... ] currently has an
unambiguous meaning, and it should stay that way.

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

Not "may" but "will".  This is an important point, not something to be
brushed aside and ignored.  Work on the Emacs core will be affected,
too.

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

That's just an example to make a point.  _ALL_ similar work on the core
will become more difficult if you press ahead with this change.

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

> I don't see how/why.

Isn't it obvious?  In place of being able to work on the Lisp form, one
will first have to extract it from the new structure, and then
afterwards write it back to that structure.  What M-: (symbol-function
'foo) currently does will, I think, become more tedious to do.  That is
the extra layer of indirection.

> In the worst case, it will replace one special case with another.

No.  It will just make things more difficult, full stop.  Or can you
identify something in your change which will make development easier?

Again, why?  What is the advantage this proposal of yours is supposed to
bring?  So far, all I've seen in the thread is tiny things about the
ability to do (funcall '(lambda ...)), the ability to cl-prin1 functions
obfuscated and suchlike.  Why?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).