Sensible interpretation of declarations in CLOS

[Juan Jose Garcia-Ripoll]

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

[Pascal Costanza]

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

Post by Juan Jose Garcia-Ripoll
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
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.

[Daniel Herring]

Content preview: 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.) [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[66.33.216.122 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/738>

Post by Pascal Costanza
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).

Post by Pascal Costanza
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

[Juan Jose Garcia-Ripoll]

On 9 Oct 2012, at 22:44, Juan Jose Garcia-Ripoll <

Post by Juan Jose Garcia-Ripoll
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

[Daniel Herring]

Content preview: 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. [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[208.97.132.177 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/740>

Post by Juan Jose Garcia-Ripoll
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

[Vladimir Sedach]

Content preview: > 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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.216.44 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(vsedach[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/741>

Post by Juan Jose Garcia-Ripoll
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

[Pascal J. Bourguignon]

Content preview: On 30/10/2012, at 01:31, Vladimir Sedach <vsedach-***@public.gmane.org>
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. > [...]

Content analysis details: (-0.6 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/742>

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.