[pro] Sensible interpretation of declarations in CLOS
Dear all, I am retaking an old question, which is the utility of type declarations in a language that has the flexibility of the MOP. In an extremely open-minded setup, where any class is prone to change, not only their structure, but also their metaclass, it would seem that a local declaration of the kind (DECLARE (MY-CLASS FOO)) would be totally useless. But... do you actually face that flexibility in real life? I mean, declarations such as (DECLARE (TYPE MY-INTEGER-TYPE FOO)) are used in actual code, where there is an implicit contract that the DEFTYPE type will not be changed in unsafe code. Can't we assume something similar when facing CLOS? What would be a reasonable optimization/safety/debug level to start considering that? Best, Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
Hi, You probably already know this, but just to make sure: The CLOS MOP specification doesn't allow any metaobjects that are instances of the predefined metaobject classes to change their classes (except for instances of forward-referenced-class). So in that regard, type declarations that refer to CLOS classes in Common Lisp are still safe. Note, however, that Common Lisp already allows for changing the (proper) names of classes. So in that regard, you don't even need the CLOS MOP to render type declarations for CLOS classes unsafe. ;) Common Lisp in general has a more traditional performance model, in that it relies on staticish compilation for performance, rather than dynamic compilation as is done in Java, JavaScript, Lua, etc. With dynamic compilation, such issues may be easier to tackle, although I suspect that this would require still some non-trivial amount of research. (Changing the metaclass of a class needs to update not only the class, but also its instances, and since you potentially have an unlimited depth in the hierarchy of metaclasses, this can be quite complicated to express in a sane way.) So my guess is that this is why the restriction in the CLOS MOP was put there in the first place, to have some amount of sanity in this regard. Just my 0.02€… Pascal On 9 Oct 2012, at 22:44, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@gmail.com> wrote:
Dear all,
I am retaking an old question, which is the utility of type declarations in a language that has the flexibility of the MOP.
In an extremely open-minded setup, where any class is prone to change, not only their structure, but also their metaclass, it would seem that a local declaration of the kind (DECLARE (MY-CLASS FOO)) would be totally useless.
But... do you actually face that flexibility in real life? I mean, declarations such as (DECLARE (TYPE MY-INTEGER-TYPE FOO)) are used in actual code, where there is an implicit contract that the DEFTYPE type will not be changed in unsafe code. Can't we assume something similar when facing CLOS? What would be a reasonable optimization/safety/debug level to start considering that?
Best,
Juanjo
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com _______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On Wed, 10 Oct 2012, Pascal Costanza wrote:
Common Lisp in general has a more traditional performance model, in that it relies on staticish compilation for performance, rather than dynamic compilation as is done in Java, JavaScript, Lua, etc. With dynamic compilation, such issues may be easier to tackle, although I suspect that this would require still some non-trivial amount of research. (Changing the metaclass of a class needs to update not only the class, but also its instances, and since you potentially have an unlimited depth in the hierarchy of metaclasses, this can be quite complicated to express in a sane way.)
All these techniques boil down to partial evaluation. Still looking for a language that allows good static PE (where time can be spent for deep analysis), good dynamic PE (where data-specific behaviors can be observed), and a good annotation mechanism for bringing it all together (possibly allowing the programmer to describe behavior that crosses both domains, but at least preserving dynamic info across processes).
On 9 Oct 2012, at 22:44, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@gmail.com> wrote:
In an extremely open-minded setup, where any class is prone to change, not only their structure, but also their metaclass, it would seem that a local declaration of the kind (DECLARE (MY-CLASS FOO)) would be totally useless.
Slava Pestov did a few really nice things with Factor. In particular, he had a mechanism that would dynamically trigger recompilation when "open coded/inlined" details changed (e.g. macro redefintion). This declaration would be a good point to store such a hook in CL... http://factorcode.org/ http://docs.factorcode.org/content/article-vocabs.refresh.html http://docs.factorcode.org/content/article-tuple-redefinition.html - Daniel
On Mon, Oct 29, 2012 at 4:35 PM, Daniel Herring <dherring@tentpost.com>wrote:
On 9 Oct 2012, at 22:44, Juan Jose Garcia-Ripoll <
juanjose.garciaripoll@gmail.**com <juanjose.garciaripoll@gmail.com>> wrote:
In an extremely open-minded setup, where any class is prone to change, not only their structure, but also their metaclass, it would seem that a local declaration of the kind (DECLARE (MY-CLASS FOO)) would be totally useless.
Slava Pestov did a few really nice things with Factor. In particular, he had a mechanism that would dynamically trigger recompilation when "open coded/inlined" details changed (e.g. macro redefintion). This declaration would be a good point to store such a hook in CL...
http://factorcode.org/ http://docs.factorcode.org/**content/article-vocabs.**refresh.html<http://docs.factorcode.org/content/article-vocabs.refresh.html> http://docs.factorcode.org/**content/article-tuple-**redefinition.html<http://docs.factorcode.org/content/article-tuple-redefinition.html>
In an ideal world, yes, but ECL must currently stick to an environment (C) which does not allow for dynamic recompilation (no clang embedded yet). I know that SBCL plays some tricks and we have used our own tricks in this sense, but I expected that something more sensible could be agreed upon. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
On Mon, 29 Oct 2012, Juan Jose Garcia-Ripoll wrote:
I expected that something more sensible could be agreed upon.
The lack of optimization in CLOS has long been a sore point. Here are some related reads. https://groups.google.com/d/topic/comp.lang.lisp/qN6U1f-mE_g/discussion http://common-lisp.net/~loliveira/tmp/sealing-proposal.txt PC seems to argue that sealing is not necessarily helpful for optimization. I tend to agree, but would still argue that a naive compiler might only try inlining things that are sealed. Sealing may also be close to what the Racket community wants. They dislike the "growth by mutation" nature of CLOS, and the uncertainty that comes with it. - Daniel
In an ideal world, yes, but ECL must currently stick to an environment (C) which does not allow for dynamic recompilation (no clang embedded yet).
A bit off-topic, but have you ever tried compiling ECL with TCC? That seems to be the best C compiler for use as a linkable library, but it only has machine code generators for a few platforms. It seems that not having a compiler around is a not unusual property for Common Lisp deployment (ECL, Parenscript, Thinlisp, commercial implementations, older implementations) and is something that the ANSI standard is IMO too strict in requiring. Vladimir
On 30/10/2012, at 01:31, Vladimir Sedach <vsedach@gmail.com> wrote:
It seems that not having a compiler around is a not unusual property for Common Lisp deployment (ECL, Parenscript, Thinlisp, commercial implementations, older implementations) and is something that the ANSI standard is IMO too strict in requiring.
The standard only requires minimal compilation for COMPILE, ie. macroexpansion. -- __Pascal Bourguignon__
participants (5)
-
Daniel Herring -
Juan Jose Garcia-Ripoll -
Pascal Costanza -
Pascal J. Bourguignon -
Vladimir Sedach