Re: Distinguishing `consp` and `functionp`

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sat, Jan 27, 2024 at 19:00:49 -0500, Stefan Monnier wrote:
> > Evasive non-answer number 1.

> That statement is mildly offensive.

But justified.  You did not answer the points I made and the questions I
put.  You gave completely unsatisfactory "answers" which didn't offer
any information.  You answered like a politician, swerving awkward
points, and derailing the discussion onto topics the questions weren't
concerned with.

The main question I have is why do you want to make your change.  You
have given no substantial reason and evaded my continual questions to
that effect.

As I see it, there is not a lot wrong with the way we handle interpreted
code, and I see your change as worsening it.

> I do not see what in my previous messages would call for it.
> [ But it may affect the rest of this message, I'm afraid.  ]

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

> Such code that can't be compiled ....

See, you're doing it again.  I never said nor meant "CAN" be compiled, I
meant code that one wishes not to compile, for purposes of debugging or
understanding.  Was that not clear?  So you've evaded answering my point
about interpreted forms.  I suppose I can't force you to answer.

> .... is extremely rare and will usually be unaffected because its
> list-representation of a function will usually not have gone through
> `eval` at all.

> > Your plan will make this more difficult.

> I guess I don't really see which kind of code you're talking about:
> examples would help.

The kind of code I'm talking about is Lisp code in .el files, and
examples can be found in the directory lisp and its subdirectories.
The functions and macros in these can be evaluated with C-x C-e for
debugging and understanding purposes.

As one example, I've recently had to enhance the backquote source.  This
isn't easy.  I'm currently able to output the lists generated by the
macros without hassle, just using `message'.  That will become more
awkward or impossible after your proposed change, won't it?

> > Let me repeat, lists are the natural, traditional representation in
> > Lisp, which bring all sorts of advantages.

> Not sure repetition helps, maybe pointing to evidence would?

I think 45 years of Emacs should be enough to establish the tradition.

> Common Lisp, Clojure, and Scheme, all disagree.  AFAIK Lisp Machine Lisp
> also disagreed.  And in practice the very vast majority of functions in
> ELisp also disagree.

There's no disagreement.  The two kinds of representation are
complementary.  You're proposing to abolish the list representation, or
at the very least make it harder to use.  That other systems may lack
this representation is no reason for us to lose it.

> > Your proposal will reduce these advantages.  For what gain?

> Since I don't think repetition helps, I'll skip this.

Repetition would be unnecessary if you would just answer the question in
the first place.  I think I've asked that question five or six times
over three posts, and you have avoided answering.  Why?

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

> By "check" you mean with your own eyes?  Or by calling `prin1` and
> parsing the result?

Both.  Also software that manipulates the printed representation of the
form will be made more complicated.

> Otherwise, I don't understand: while my current patch has the bug that it
> makes `byte-code-function-p` return non-nil on interpreted functions,
> I already mentioned that it's a problem in the patch.

Your proposed patch has the bug that it dilutes and weakens the meaning
of #[ ... ].  It's as if you took the meaning of the green traffic
light, which unambiguously means "go" and made it mean "go unless you're
driving a heavy goods vehicle", or something like that.

You still haven't answered my question as to why you're using #[ ... ],
and it seems likely that it was just a matter of convenience while
writing your patch.  It was less work.  Please consider that it might
not be a good idea to use it for real.

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

> The patch *does* touch those places, BTW.

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

> Care to point to existing code that extracts data from a function value
> and then puts it back (presumably slightly modified)?

I already have done.  symbol-function, fset.

> > What M-: (symbol-function 'foo) currently does will, I think, become
> > more tedious to do.

> ? `symbol-function` is unaffected.

So if I write

   (defun foo (bar) (car bar))

into *scratch* and evaluate it, then do M-: (symbol-function 'foo), what
I will get back on my terminal after your change will be exactly

   (closure (t) (bar) (car bar))

, will it?

> > That is the extra layer of indirection.

> Could it be you're confused?

No, it couldn't.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).