On Dec 22, 2015, at 08:26 , james anderson <james.anderson@setf.de> wrote:
good morning;
On 2015-12-21, at 20:15, Attila Lendvai <attila@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@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 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 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…
]