Pre-submission discussion: code walking

[Michael Raskin]

>
>> 
>> My plan for walkability is: compliance with CDR-NN requires having
>> a package with name CDR-NN that has all the symbols defined in CDR-
>> NN.
>> 
>
>IMHO if CDR's are truly meant as a process to augument standarization
>then all that should be in a single package (with an additional "CDR-
>USER" package which uses CL and CDR and is not locked). That will
>ensure that there are no symbol conflicts and it is indeed a possible
>candidate for inclusion a "base" package. Also too many packages is a
>tedious disease of many systems.

I agree with the goal of eventually having a usable CDR/CDR-USER 
package.

I don't think this should be defined by the next coming CDR.

Currently the CDR process is defined in a way that is best suited for 
defining small isolated things. I agree it would be useful to define
a decision-making process that could be used for filling a single
extension namespace in a consistent and widely respected way. I think
defining such a process requires a discussion with buy-in from multiple
implementations, and I hope to revive CDR as a recognised discussion 
place, but my plan starts with discussing something concrete — starting
with a meta-discussion about rules has its own failure modes.

So I am not ready to start defining a CDR package with the 
(coordination) tools I see, but I think there is hope to improve the
situation.

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.

In other portability-sensitive areas, I think CFFI and Bordeaux-Threads
will stay but it is good to have a defined foundation that a new
implementation or a fork can provide and immediately get full support.