flet/labels/macrolet and environments

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

{ The mailer seems to have bounced the first time I sent this.
  Apologies to anyone who receives it twice.  kab } 

    Date: Thu, 5 Nov 87 04:20 EST
    From: Jeff Mincy <mincy@Think.COM>
  
    ... These forms {special-forms -- kab} really are special, users have
    to understand them seperately from other things like function call. ...
    You still can't funcall a special-form. 

  I don't think this is an adequate argument by itself.  Many macros also
have peculiar syntax, which has to be learned on a case by case basis by
the user.  You also can't funcall macros.  But you can locally redefine
them.

  There is a certain simplicity to the description of flet &etc.  It says
that within the specified scope, named functional references which match
the specified names refer to the specified definitions.  If the names of
special-forms cannot be shadowed, you have to add a statement to that
effect as an additional caveat.

  Note that I am NOT arguing that it is necessarily reasonable for a user
to write such code, since it may very well break things.  But this is true
for any local redefinition, especially of 'standard' names, like the
built-in Common Lisp names that are in the Lisp package.  I would consider
it perfectly acceptable for a compiler to issue some sort of style warning
when it encounters a local redefinition of a standard Common Lisp function,
as long as there is some way for the user to turn it off if that is REALLY
what he means to do.  I understand that some compilers already do this.  In
fact, I've just added this to my todo list, for the next time I start major
surgery on our compiler.

  Its interesting to note that everywhere else I can find where the issue
of possibly redefining a special-form comes up, CLtL specifically says it
is an error to do so, yet is totally silent on the subject regarding local
redefinition.  Not that I'm putting this forward as an argument in favor of
allowing shadowing, since it doesn't address the question of what is the
RIGHT thing to do.  I was just wondering if it was an oversight, or if it
was intentional.

  As a random additional piece of dirt to throw into this mess, what
happens if you have an flet &etc in which the same name appears twice?  My
guess is that, with the usual left-to-right order of evaluation, combined
with the scoping rules, the most obvious answer is that the LAST of the
definitions ends up taking precedence, and the previous one(s) get ignored.
Of course, the left-to-right ordering is kind of a red herring, since the
order is left undefined, like in a LET form, where the same question
arises.  Very peculiar, and probably worth a compiler warning.


    ... I would suggest that it {local-function-p -- kab} return a second
    value of t if the symbol is a lexical macro.

  I had thought about this, and in an earlier version actually had it in,
but decided it probably isn't necessary.  In the places I've seen where
this function would get used, the second value would probably only be
useful as an efficiency hack, allowing you to avoid superflously calling
macroexpand on a form that references a local function, rather than a
macro.  Not being one to sneer at efficiency issues, I think I've changed
my mind again, and agree with your suggestion.


    I am not really convinced that this {augment-function-environment --
    kab} is needed.  ...

  You need something like augment-function-environment so that your code
walker can process an flet/labels/macrolet form and update the environment
you are passing around in a way that keeps it compatable with the Common
Lisp implementation's representation of environments, so that you can pass
the updated environment to macroexpand.  Look at the PCL code walker for an
example of the horrible kludges people are forced to try in order to write
something that is at least semi-portable.

kab
-------