RE: [External] : Re: Question about native compilation (bug?)

[Drew Adams]

> Redefining a primitive (thing that is not recommended but often done)
> one must at least use the same signature as the original one.  I don't
> think we support the case where the new definition is of a different
> signature.  Native compilation might be just more sensitive in this
> unsupported condition.

I don't know whether the same problem arises if
the redefined function has a Lisp instead of a
C definition.  If not, then what you say might
have a bit more sway.

Is that the case - is this problem limited to
redefining functions defined in C?  Or does it
apply also to redefining functions defined in
Lisp?

Lisp itself has always been a dynamic language
and a dynamic programming environment.  That
has included redefining things on the fly.
Since Day One.

And without native compilation we _do_ support
redefining to a definition that has a different
signature.  The actual code in question doesn't
raise an error without native compilation, in
the described scenario (i.e., for a call whose
source code passes only 3 args).

To be clear, I'm not so much arguing about this
as raising a question about it.  I can guess
there are reasonable arguments on both sides of
the question.
___

Imagine this scenario, to take this away from
the actual case where I discovered the problem:

1. A function with two args, both optional, is
defined in Lisp.  But all existing calls to the
function pass only the first arg. 

And imagine that the code gets native-compiled.

2. Later the function is redefined in such a way
that it doesn't ever need the second arg - the
new definition has only one arg (optional).

In a "normal", traditional Lisp environment, no
code changes would be needed. No error would be
raised for any of the existing calls to that
function, because they all pass only one arg.

I don't think this scenario is far-fetched.

Should it really be the case that just because
the code was natively compiled all of the calls
to that function should now raise an error,
because native compilation decided to pass two
args for each call, the second arg being nil?
In effect, native compilation ignores the
redefinition, when it comes to existing calls.
It has baked-in the idea that there are 2 args
and so it passes 2 args in each call.

To me, native compilation should ideally just
be "plumbing".  It shouldn't (again, ideally)
change the _behavior_ of code, other than wrt
performance.  The behavior should (ideally) be
the same as without native compilation.

I don't know the implementation of native
compilation, and I can't speak to whether it
could easily _not_ pass explicit nil for all
missing optional args.  If doing that would be
a game changer (impossible, hard, or with bad
consequences) then we should just live with
what we have, I guess.  But in that case maybe
we should at least document this behavior
difference with native-compilation?

But if native compilation could just as well
pass only the actual arguments that get passed
in the source code, instead of adding nil args
for all optional args, that would be better,
I think.  It would be faithful to the spirit
of Lisp, and faithful to the source code and
the byte-compiled code.

Would such a fix be feasible / easy?  If so,
would it drastically impact performance
negatively?  If not hard to fix and no bad
consequences from doing so, how about making
such a fix?