Type propagation proposal
james anderson
james.anderson at setf.de
Tue Dec 22 07:26:27 UTC 2015
good morning;
> On 2015-12-21, at 20:15, Attila Lendvai <attila at lendvai.name> wrote:
>
> i wrote up some ideas here:
>
> https://github.com/cffi/cffi/wiki/Type-propagation-proposal
>
> you're invited to comment/edit it.
[transported from otherwise private correspondence…]
> On 2015-12-22, at 00:16, Attila Lendvai <attila at lendvai.name> wrote:
>
> hello,
>
> […]
>
>> the question is, did you consider using declarations and environments?
>> i have found the sbcl implementation of those to be quite serviceable and i
>> would expect it to provide all of the definition and access facilities which
>> type-based operations could require.
>
>
> as this is CFFI it should be portable, but i'm willing to give this up
> if sane implementations can be made to work. there's an issue already
> with portable access to the environment, but that has been dealt with
> already.
>
> do you think this could be implemented portably in a sane way? if so
> maybe we should do that, but i never used user declarations.
i have never tried to validate my particular current use of the declaration facilities against some implementation other than sbcl, but i recall using them in lispworks, allegro and even mcl and see that ccl appears to implement them as well.
the are cltl2 rather than ansi, but as they expose something which any implementation must already implement, they are a reasonable expectation.
for sbcl i recall to need only to include :sb-cltl2 as an asdf dependency.
the mechanism is pretty much transparent as to what the declaration can carry-
that is, subject to scope and extent requirements, you can do pretty much whatever you want.
>
> also, getting the CFFI type of variables is only part of the
> story. making nested calls know about each other also needs to be
> solved.
that declarations are, first order, a compile-time facility does limit the information which they themselves can carry, but that does not prevent one from using them to govern code generation which carries information into the dynamic environment.
>
> PS: let's move this to the mailing list, feel free to quote me there.
best regards, from berlin,
More information about the cffi-devel
mailing list