Re: Distinguishing `consp` and `functionp`

[Stefan Monnier]

> Evasive non-answer number 1.

That statement is mildly offensive.
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 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.

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

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

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

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

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.

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

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

? `symbol-function` is unaffected.

> That is the extra layer of indirection.

Could it be you're confused?


        Stefan