[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)

My initial reaction to this proposal is that it makes the behavior of
EVAL-WHEN -- particularly its nesting behavior -- even harder to
understand than the description in CLtL.  The proposal does seem to
solve the problem but it took me quite a while even to verify that
this proposal is compatible with CLtL for top-level EVAL-WHENs and
step through the examples to see how they work. 

I think it would be helpful if the writeup included an analysis to
summarize the nesting behavior:

  For a <body> nested inside of several top-level EVAL-WHENs:

    (1) Normal interpreter of <body> happens when -all- of
        the nested EVAL-WHENs specify the EVAL situation.

    (2) Normal compiler processing of <body> happens when -all- of the
        nested EVAL-WHENs specify the LOAD situation.

    (3) Compile-time evalution of <body> happens when -one- of the
        EVAL-WHENs specifies the COMPILE situation.  If that EVAL-WHEN
        also specifies LOAD, then -all- of the ones nested inside of
        it must specify either COMPILE or EVAL.  If that EVAL-WHEN
        does not specify LOAD, then -all- of the ones nested inside of
        it must specify the EVAL situation.

The asymmetry of the last item bothers some people.  In particular,
some people write

    (eval-when (load)
        (defmacro foo ...))

thinking that this would make FOO defined only at load time and not at
compile time.  I think the writeup should at least mention that this
doesn't work, and also provide a rationale for why it shouldn't.  This
is really the only part of the behavior this proposal specifies that
gives me any problems (my other complaints are just with it being hard
to understand).

Unless this new proposal has overwhelming support, I think I'd like to
continue to pursue the ideas we were developing earlier and present
both proposals.  The proposal from Version 4 was certainly much easier
to understand and I think it would be much easier to tinker with the
nesting behavior it specifies than what Version 5 specifies.  One
thing I'd like to do in any further revisions to Version 4 is to use
terms that are not as loaded as "top-level" and "non-top-level" to
describe what EVAL-WHEN should or shouldn't pass through, perhaps
something like "visible" and "shielded".

So, let's hear from some of the rest of you.  Are you all happy with
this proposal or would you like to see something simpler?

-Sandra
-------