<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">good afternoon;<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 2015-12-22, at 12:13, Marco Antoniotti <<a href="mailto:marcoxa@cs.nyu.edu" class="">marcoxa@cs.nyu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><blockquote type="cite" class="">On Dec 22, 2015, at 08:26 , james anderson <<a href="mailto:james.anderson@setf.de" class="">james.anderson@setf.de</a>> wrote:<br class=""><br class="">good morning;<br class=""><br class=""><blockquote type="cite" class="">On 2015-12-21, at 20:15, Attila Lendvai <<a href="mailto:attila@lendvai.name" class="">attila@lendvai.name</a>> wrote:<br class=""><br class="">i wrote up some ideas here:<br class=""><br class=""><a href="https://github.com/cffi/cffi/wiki/Type-propagation-proposal" class="">https://github.com/cffi/cffi/wiki/Type-propagation-proposal</a><br class=""><br class="">you're invited to comment/edit it.<br class=""></blockquote><br class=""><br class="">[transported from otherwise private correspondence…]<br class=""><br class=""><blockquote type="cite" class="">On 2015-12-22, at 00:16, Attila Lendvai <<a href="mailto:attila@lendvai.name" class="">attila@lendvai.name</a>> wrote:<br class=""><br class="">hello,<br class=""><br class="">[…]<br class=""><br class=""><blockquote type="cite" class="">the question is, did you consider using declarations and environments?<br class="">i have found the sbcl implementation of those to be quite serviceable and i<br class="">would expect it to provide all of the definition and access facilities which<br class="">type-based operations could require.<br class=""></blockquote><br class="">as this is CFFI it should be portable, but i'm willing to give this up<br class="">if sane implementations can be made to work. there's an issue already<br class="">with portable access to the environment, but that has been dealt with<br class="">already.<br class=""></blockquote></blockquote><br class="">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.<br class=""></div></blockquote><div class=""><br class=""></div>cool.</div><div class="">mine has been that define-declaration and declaration-information interoperated sufficiently to be effective.</div><div class="">our experience evidently differs as to how well one can work under the evident constraints.</div><div class="">whether they would prevent its use in this endeavour would be a matter to be demonstrated.</div><div class="">despite deficiencies, i would continue to maintain, it is more effective to drink from a half-full glass, that to die from dehydration.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">do you think this could be implemented portably in a sane way? if so<br class="">maybe we should do that, but i never used user declarations.<br class=""></blockquote><br class="">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.<br class="">the are cltl2 rather than ansi, but as they expose something which any implementation must already implement, they are a reasonable expectation.<br class=""></blockquote><br class="">Alas, they are not. At this point only Allegro offers a working (and incomprehensibly non-cltl2-compliant - cfr., the return values order) version. </div></blockquote><div class=""><br class=""></div>then the code which i use to propagate solution field type information in <a href="http://dydra.com" class="">dydra.com</a> when it compiles sparql queries to native code in sbcl is a figment of my imagination.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""> CMUCL and CCL do a reasonable job as does LW.<br class=""><br class="">SBCL has lost SB-CLTL2 in the most recent (Mac) version.<br class=""></div></blockquote><div class=""><br class=""></div>that is unfortunate and a cause for immediate consternation, but not grounds to dismiss that implementation, which does exist.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class="">ABCL’s maintainers are on record (personal communication :) :) :) ) as being ready to provide CLtL2 Chapter 8.5 functions “Very Soon Now”(TM).<br class=""><br class="">I cannot say anything for ECL, CLISP or other implementations at this point.<br class=""><br class=""><blockquote type="cite" class="">for sbcl i recall to need only to include :sb-cltl2 as an asdf dependency.<br class=""></blockquote><br class="">See above.<br class=""><br class=""><blockquote type="cite" class="">the mechanism is pretty much transparent as to what the declaration can carry-<br class="">that is, subject to scope and extent requirements, you can do pretty much whatever you want.<br class=""></blockquote><br class="">If it worked.<br class=""></div></blockquote><div class=""><br class=""></div>if it did not, <a href="http://dydra.com" class="">dydra.com</a> would stop working.</div><div class=""><br class=""></div><div class="">[…</div><div class="">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.</div><div class="">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…</div><div class="">]</div><div class=""><br class=""></div></div><div class="">best regards, from berlin,</div></body></html>