Type propagation proposal

[james anderson]

good afternoon;

> On 2015-12-22, at 12:13, Marco Antoniotti <marcoxa at cs.nyu.edu <mailto:marcoxa at cs.nyu.edu>> wrote:
> 
> 
>> On Dec 22, 2015, at 08:26 , james anderson <james.anderson at setf.de <mailto:james.anderson at setf.de>> wrote:
>> 
>> good morning;
>> 
>>> On 2015-12-21, at 20:15, Attila Lendvai <attila at lendvai.name <mailto:attila at lendvai.name>> wrote:
>>> 
>>> i wrote up some ideas here:
>>> 
>>> https://github.com/cffi/cffi/wiki/Type-propagation-proposal <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 <mailto: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.
> 
> I beg to differ.  There is NO code out there that correctly and portably has access to “the environment”.  I.e., at the level of CLtL2 Chapter 8.5.

cool.
mine has been that define-declaration and declaration-information interoperated sufficiently to be effective.
our experience evidently differs as to how well one can work under the evident constraints.
whether they would prevent its use in this endeavour would be a matter to be demonstrated.
despite deficiencies, i would continue to maintain, it is more effective to drink from a half-full glass, that to die from dehydration.

> 
>>> 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.
> 
> Alas, they are not.  At this point only Allegro offers a working (and incomprehensibly non-cltl2-compliant - cfr., the return values order) version.

then the code which i use to propagate solution field type information in dydra.com <http://dydra.com/> when it compiles sparql queries to native code in sbcl is a figment of my imagination.

>  CMUCL and CCL do a reasonable job as does LW.
> 
> SBCL has lost SB-CLTL2 in the most recent (Mac) version.

that is unfortunate and a cause for immediate consternation, but not grounds to dismiss that implementation, which does exist.

> 
> ABCL’s maintainers are on record (personal communication :) :) :) ) as being ready to provide CLtL2 Chapter 8.5 functions “Very Soon Now”(TM).
> 
> I cannot say anything for ECL, CLISP or other implementations at this point.
> 
>> for sbcl i recall to need only to include :sb-cltl2 as an asdf dependency.
> 
> See above.
> 
>> 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.
> 
> If it worked.

if it did not, dydra.com <http://dydra.com/> would stop working.

[…
i would observe, that, while there may be eminent value to producing the much better, much fuller and completely portable compile-environment introspection extension, it might still be worthwhile, to see what needs to be rectified in the ostensible standard to achieve sufficient facility, but as noted, i see half-full glasses as eminently worthwhile things, which may skew my perspective.
and, then there is the nagging concern about whether it might be more robust over the longer term to have vendors respond to deficiencies and endorse a standard, than to have a perhaps even more complete and powerful, but not vendor-supported facility chase implementation internals…
]

best regards, from berlin,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20151222/bf91423e/attachment.html>