Type propagation proposal
i wrote up some ideas here: https://github.com/cffi/cffi/wiki/Type-propagation-proposal you're invited to comment/edit it. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The first thing you have to do if you want to raise nice kids, is you have to talk to them like they are people instead of talking to them like they're property.” — Frank Zappa (1940–1993), 'The Howard Stern Show' (1987)
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.
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,
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.
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. CMUCL and CCL do a reasonable job as does LW. SBCL has lost SB-CLTL2 in the most recent (Mac) version. 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. Having said that, I point you guys to CLAST: http://clast.sourceforge.net; any help is welcome, especially in lobbying the implementors to support CLtL2 Chapter 8.5. I would like to have you note that CLAST constructs a “source level” AST for CL code, and that the PARSE-FORM generic function is the “form-level” hook to actually write an extension for CFFI definition forms. Cheers -- Marco Antoniotti
good afternoon;
On 2015-12-22, at 12:13, Marco Antoniotti <marcoxa@cs.nyu.edu <mailto:marcoxa@cs.nyu.edu>> wrote:
On Dec 22, 2015, at 08:26 , james anderson <james.anderson@setf.de <mailto:james.anderson@setf.de>> wrote:
good morning;
On 2015-12-21, at 20:15, Attila Lendvai <attila@lendvai.name <mailto:attila@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@lendvai.name <mailto: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 <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,
Dear James, I wish I had access to a “full glass” implementation of CLtL Chapter 8.5. Non GPLed (sorry guys) is a requirement as well. I am not aware of the implementation you use in hydra.com; if you refer to the “portable” one from Franz (or a variation), that still needs low-level support from each implementation. If you have an implementation you wrote, that would be welcome as well. But, AFAIK, at the time of this writing you cannot download or buy a CL implementation and hope for full-glass compliance with the CLtL2 chapter (except for Allegro, modulo the “return values switch”). If you can point me to an implementation of CLtL Chapter 8.5 that would be good. But I think that the best course of action is to lobby the CL implementors to support CTtL Chapter 8.5. That would simplify life quite a bit. Cheers — Marco
On Dec 22, 2015, at 13:59 , james anderson <james.anderson@setf.de> wrote:
good afternoon;
On 2015-12-22, at 12:13, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
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… ]
-- Marco Antoniotti
good evening;
On 2015-12-22, at 17:46, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Dear James,
I wish I had access to a “full glass” implementation of CLtL Chapter 8.5. Non GPLed (sorry guys) is a requirement as well.
that is a noble goal, but may not necessary for the matter under discussion.
I am not aware of the implementation you use in [dydra].com;
i had hoped it would be sufficiently clear for me to indicate that "i have never tried to validate my particular current use of the declaration facilities against some implementation other than sbcl” and, with respect to the dydra implementation, that "it compiles sparql queries to native code in sbcl”.
if you refer to the “portable” one from Franz (or a variation), that still needs low-level support from each implementation. If you have an implementation you wrote, that would be welcome as well. But, AFAIK, at the time of this writing you cannot download or buy a CL implementation and hope for full-glass compliance with the CLtL2 chapter (except for Allegro, modulo the “return values switch”).
if your criteria has now evolved to "full glass compliance”, i have not done the necessary compliance testing to respond to that. the original note proposed that franz offers the only “working” version, whereby, as phrased, even non-compliance was permitted. to which i averred, that, by some measure of working, there is at least one other implementation.
If you can point me to an implementation of CLtL Chapter 8.5 that would be good.
But I think that the best course of action is to lobby the CL implementors to support CTtL Chapter 8.5. That would simplify life quite a bit.
i believe the more pertinent question for this thread would be which introspection facilities would be required to implement this extension to cffi and do those particular facilities have wide and consistent enough support to provide a basis for that extension. best regards, from berlin,
A correction on my previous posts. It looks like that my setup on my Mac (I don’t know if this applies to other people as well), messed up my SBCL upgrade. After the third run of ‘install.sh’, the script was finally convinced to copy the ‘contrib’ folder as well. Now SB-CLTL2 can be required as expected. Cheers — MA
On Dec 22, 2015, at 18:17 , james anderson <james.anderson@setf.de> wrote:
good evening;
On 2015-12-22, at 17:46, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Dear James,
I wish I had access to a “full glass” implementation of CLtL Chapter 8.5. Non GPLed (sorry guys) is a requirement as well.
that is a noble goal, but may not necessary for the matter under discussion.
I am not aware of the implementation you use in [dydra].com;
i had hoped it would be sufficiently clear for me to indicate that "i have never tried to validate my particular current use of the declaration facilities against some implementation other than sbcl” and, with respect to the dydra implementation, that "it compiles sparql queries to native code in sbcl”.
if you refer to the “portable” one from Franz (or a variation), that still needs low-level support from each implementation. If you have an implementation you wrote, that would be welcome as well. But, AFAIK, at the time of this writing you cannot download or buy a CL implementation and hope for full-glass compliance with the CLtL2 chapter (except for Allegro, modulo the “return values switch”).
if your criteria has now evolved to "full glass compliance”, i have not done the necessary compliance testing to respond to that. the original note proposed that franz offers the only “working” version, whereby, as phrased, even non-compliance was permitted. to which i averred, that, by some measure of working, there is at least one other implementation.
If you can point me to an implementation of CLtL Chapter 8.5 that would be good.
But I think that the best course of action is to lobby the CL implementors to support CTtL Chapter 8.5. That would simplify life quite a bit.
i believe the more pertinent question for this thread would be which introspection facilities would be required to implement this extension to cffi and do those particular facilities have wide and consistent enough support to provide a basis for that extension.
best regards, from berlin,
-- Marco Antoniotti
On Mon, Dec 21, 2015 at 7:15 PM, Attila Lendvai <attila@lendvai.name> wrote:
This is a good idea. In the past, we've talked about implementing the (SB-)ALIEN API on top of CFFI, which would require something along these lines. Regarding your concrete proposal, how would the API look like? It would be nice to keep the same API, but it's not always possible to suppress the type arguments because of where they're positioned in the lambda lists. I agree with James that it would be nice to use declarations and environments, if feasible. Cheers, -- Luís Oliveira http://kerno.org/~luis/
participants (4)
-
Attila Lendvai -
james anderson -
Luís Oliveira -
Marco Antoniotti