Pre-submission discussion: code walking
Daniel KochmaĆski
daniel at turtleware.eu
Fri Apr 26 11:05:08 UTC 2019
> 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.
>
> 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.
>
CFFI in ECL's case is baked by ECL's UFFI implementation (ECL
implements UFFI protocol and said protocol is fairly simple).
Daniel
More information about the cdr-discuss
mailing list