RE: lexical-binding questions

["Drew Adams" <drew.adams@oracle.com>]

> > Now we have lexical-binding in Emacs, it could be nice to 
> > implement the declare features of CL. (inline too)
> 
> Just because CL has lexical-scoping doesn't mean that Elisp added
> lexical scoping to be more like CL ;-)

Agreed.  Not "just because".  But similarly, just because Emacs Lisp is not
Common Lisp does not mean that it should always do things differently. ;-)

IOW, I think (hope) we agree that there should be good, preferably
Emacs-specific reasons why we choose to do things differently (or even the
same).

But when other things are equal (which they seldom but sometimes are), it can
help users who are familiar with Common Lisp if we do things similarly.  CL is
perhaps the closest well-known Lisp to Emacs Lisp in both design and aims.

And there are usually good reasons why CL defines & handles things the way it
does.  That can serve as a starting point for whatever you decide for Elisp.
IOW, what CL does is always worth looking at, before deciding how to roll your
own.

> Regarding `inline': I hate defsubst and would rather encourage people
> not to use it, because Elisp supports much too poorly (it doesn't do
> what you want when you try to use ELP, trace-function, debug-on-entry,
> defadvice, etc...).

+1  (but one could give a similar parenthetical remark about `defadvice')

> A much more productive patch would be to speed up function calls from
> byte-code functions to byte-code functions by performing them without
> leaving the byte-code interpreter

Sounds good.

> (currently the code does a ridiculous dance where the byte-code
> interpreter takes the args from the byte-code stack, passes them
> to Ffuncall which calls funcall_lambda which then calls
> exec_byte_code which sets up a new byte-code stack and copies the
> args to this new stack, to finally run the destination byte-code).

Any reason for that as far as you can tell, apart from hysterical raisins?