Pre-submission discussion: code walking

[Michael Raskin]

>> A part of the story is that to get the ball rolling I want
>> walkability
>> extensions to be as cheap as possible to implement. So I want to give
>> the implementations some choice in implementing the CDR; which means 
>> that environment handling support is not directly for users as much
>> as
>> for building a portable library on top of it. Agreeing on a single
>> API
>> is more risk and more negotiations than analyzing the existing APIs
>> and
>> defining various sufficient subsets that are already sufficient, as
>> well
>> as identifying the options for improvements when more is available.
>> User
>> APIs on top of that can evolve as Quicklisp-installable libraries
>> before
>> we need to agree on the precise best approach.
>
>I think that there should be a single spec to avoid incompatible
>coverage. I agree that having it relatively low-level is fine. I think
>that a test suite covering various corner cases would be a very good
>initial step. We could include it in ansi-test library in ansi-beyond
>suite.

>From the point of view of better chances of support from diverse 
implementations, I expect the suboptimal Javascript-style non-uniform
support with easy feature-probing and «polyfill» libraries to be useful
for solving chicken-and-egg problem: we need useful libraries to show
something is worth implementing well, and we need working support to try
writing the useful libraries.