Re: Declaring Lisp function types

[Adam Porter]

>   > I worry that these declarations will become frequent, even pervasive,
>   > and then effectively compulsory.  Then we won't have Lisp any more,
>   > we'll have something more like C.
>
>   > I think somebody said somewhere that the declarations will be
>   > "voluntary", but things that start off voluntary have a nasty habit of
>   > first becoming pervasive, then all but universal, and then compulsory.

I don't think these are fair arguments.  They're beyond speculative. 
We're here because we want to write this kind of software in Emacs Lisp, 
not in C.  No one wants mandatory type declarations.  And the Common 
Lisp model, which Andrea seems to be inspired by and generally 
following, does not make such declarations mandatory either.

The same kind of argument could be made about, e.g. Edebug 
instrumentation declarations: "If we allow macros to have these, they 
could start off voluntary, but then become pervasive, then compulsory. 
So we'd better not have them at all, then."  Obviously, they have not 
turned out that way; they are added where they are useful and needed, 
and they are of great benefit.  No one has any intention of making them 
mandatory; if they are not provided, then the macro is simply not 
instrumented as usefully.  There is no slippery slope here.

In the same way, if a function has type declarations, and--someday--the 
compiler could use them to produce more efficient code, that would be 
great.  Otherwise, the function will be compiled as it is now.

This is, as far as I can tell, what Andrea has always intended to do, 
time permitting, and he has made this clear from all of his writing on 
the topic for the past few years.  To suggest that he intends otherwise 
would seem quite unfair to him.

> That is my concern as well.  If we let native compilation
> lure us down the path of changing the Emacs Lisp language
> so as to make native-compiled code faster, there is almost
> no limit to how much time we could put into it.  There are
> always things we could do to keep optimizing some cases.
>
> This will tend to draw effort away from other sorts of improements in
> GNU Emacs.   We should decline to go down that path.

I don't think that's a reasonable way to view this matter.  Emacs is 
developed voluntarily.  It's a rare occasion that someone comes along 
who has the expertise, interest, and time to contribute something as 
challenging as compiler optimizations, such as Andrea has graciously 
given to us (really, a whole new compiler implementation).  When it 
happens, who are we to say that they should apply their effort 
elsewhere.  We should gratefully accept their contributions and 
encourage more of them as they are able to provide.

Emacs needs these kinds of significant developments--ones which happen 
rarely but provide benefits for many years--to sustain it in the face of 
competition that's developed by teams of full-time engineers working at 
large companies.  Woe unto us if we turn them away by asking them to 
volunteer their time on something not according to their interest.