Pre-submission discussion: code walking

[Michael Raskin]

>>> Finally, COPY-ENVIRONMENT may and LEXICAL-ENVIRONMENT also be problematic.
>> 
>> Note that B-level and C-level support requires some properties of underlying implementation that do not currently hold for many popular ones.
>
>I may have misread the proposal, but, AFAIU, even what you call “Level A” cannot be easily provided without a commitment by the implementations.

OK, then I failed at wording. 

The intention is: implementation provides an arbitrary _subset_ of symbols described in the document, and symbols that it decides to provide shall match the description. The level-B adds sane expansion requirement, and level-B and level-C make sure at least something is provided.

Unless an implementation reuses the names while changing the semantics, a third party can track what names correspond to what functionality and wrap everything that is available into CDR-NN functions (and ignore the rest). This matches exactly the intention of level-A compliance.

Do you think that splitting a separate CDR for implementation packages and all-optional functionality would make this easier to understand? In that case what are the best words for optional/required functionality? Walkability level A defines OPTIONAL symbols to provide, but flexible hash-table interface defines MANDATORY functionality?

>> Also note that I want to provide common names for much more functionality than I want to require. It is enough to have WITH-AUGMENTED-ENVIRONMENT for B-level complieance, and COPY-ENVIRONMENT (or standalone AUGMENT-ENVIRONMENT) is not required even on the C-level. It is purely a «please tell me if you already provide this».
>> 
>> Frankly, I think SLIME wants to do something that boils down to ability to define ENVIRONMENT-ENTRY-NAMES, so that shouldn't be too bad.
>> 
>> LEXICAL-ENVIRONMENT has very weak requirements, I think on most implementations it can be defined by a third-party library.
>> 
>> WITH-PARENT-ENVIRONMENT is definitely completely optional — on the other hand, if the implementation never tracks parent environments, it is OK to always have NIL there.
>
>LW already has SYS:MAP-ENVIRONMENT which looks like ENVIRONMENT-ENTRY-NAMES, so, yes, it is definitively doable, like everything else, given a “sufficiently supportive implementation/vendor”.
>
>I just feel that CDRs should not make too many requests on the implementation.

Well, level-A would be a large compatibility enhancement and it expects only wrapping or aliasing the functionality already there.

>Apart from that, I would also note that listing names should not be sufficient for a CDR.  Functions and macros signatures should also be described (*), as well as types.
>
>As for the specific content, I would also explicitly refer to the CLtL2 Environment Section 8.5.

I did provide signatures for some but apparently not all of the symbols added compared to CLtL2, and should probably also add signatures for CLtL2 names as well, thanks.

PS. Is there anything I can do to help make the links in the bottom of the CDR project page lead to webpages of archives?