[cdr-discuss] file-local variables
Hello, here's a proposition for a new CDR about "file-local variables": extending the behavior of *PACKAGE* and *READTABLE* to user-defined variables. This corresponds to one point in my ELS 2011 lightning talk. I'm just providing the first version in text form for easy quoting. Comments welcome. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On 26 April 2011 11:34, Didier Verna <didier@lrde.epita.fr> wrote:
I'm just providing the first version in text form for easy quoting. Comments welcome.
A mechanism like this would make many things easier. While ASDF can do this trivially, in order for vendor support to be nice for everyone involved, a two things need to be addressed: 1. Should *FEATURES* identify support for this? Maybe :FILE-LOCAL-VARIABLES? 2. What package does MAKE-VARIABLE-FILE-LOCAL reside in? I have a controversial suggestion. COMMON-LISP-EXTENSIONS, aka CL-EXT. CDR-EXT or CDR-11 are less controversial alternatives. Cheers, -- Nikodemus
Nikodemus Siivola wrote:
While ASDF can do this trivially, in order for vendor support to be nice for everyone involved, a two things need to be addressed:
1. Should *FEATURES* identify support for this? Maybe :FILE-LOCAL-VARIABLES?
2. What package does MAKE-VARIABLE-FILE-LOCAL reside in? I have a controversial suggestion. COMMON-LISP-EXTENSIONS, aka CL-EXT. CDR-EXT or CDR-11 are less controversial alternatives.
I wouldn't have any problem with every vendor using her own, already existing, extension package (e.g. sb-ext in your case). CDR packages is a nice idea but I'm wondering about a couple of things: - having a single CDR package sounds weird. How is "CDR" a relevant criterion for classification? Why would it be better than just using sb-ext? - CDR-<num> sounds better although it might lead to package proliferation: every time a CDR is updated, it gets a new number. - However, we can also have CDR-11 imported in CDR, imported in SB-EXT :-) As for *FEATURES*, I'm all in favor of having :CDR-<num> listed in there when appropriate. This could also be the topic for a new CDR ;-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On 26 April 2011 12:55, Didier Verna <didier@lrde.epita.fr> wrote:
I wouldn't have any problem with every vendor using her own, already existing, extension package (e.g. sb-ext in your case). CDR packages is
So the idea is that users can do (defpackage :foo (:import-from :cl #+sbcl sb-ext :acl :excl #+ccl :ccl #:make-variable-file-local)) and then have FOO::MAKE-VARIABLE-FILE-LOCAL mean the same thing across implementations? Cheers, -- Nikodemus
Nikodemus Siivola wrote:
So the idea is that users can do
(defpackage :foo (:import-from :cl #+sbcl sb-ext :acl :excl #+ccl :ccl #:make-variable-file-local))
and then have FOO::MAKE-VARIABLE-FILE-LOCAL mean the same thing across implementations?
Yeah. This is something one needs to do in several occasions already (for instance to get MOP functions from packages named differently across implementations) and I don't think it's such a big deal. But still, you raised an interesting and more general idea, which is to decide on a general mechanism for supporting/advertizing CDR features. This could be worth a discussion in another thread maybe. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On 26 April 2011 14:31, Didier Verna <didier@lrde.epita.fr> wrote:
Yeah. This is something one needs to do in several occasions already (for instance to get MOP functions from packages named differently across implementations) and I don't think it's such a big deal.
Unless you use CLOSER-MOP. :) I think a semi-standard package for extensions like this would be good, but that's probably just my idealism speaking. Cheers, -- Nikodemus
Hi packages and extensions are a pet-peeve of mine. :) I feel strongly on the subject and I have followed the following conventions in my recent coding (conventions which hinge on a non-standard and unadvertised feature of many implementations: see below). Most of my packages are now named as "IT.UNIMIB.DISCO.MA.XXX.YYY.ZZZ" Then they may have nicknames, which can be "COMMON-LISP.EXTENSIONS.DATA-AND-CONTROL-FLOW.STUFF" and "CL.EXT.DACF.STUFF" and "STUFF". The naming scheme I adopted for the "COMMON-LISP.EXTENSIONS.CH" packages is that CH is the name of one of the ANSI chapters. Of course, one could imagine a "COMMON-LISP.EXTENSIONS.NETWORKING" package and a "COMMON-LISP.EXTENSIONS.MULTIPROCESSING" package for things which do not appear in the ANSI. I feel this satisfies my inner need for order. Two notes: The whole thing is predicated on an implementation raising an error (a PACKAGE-ERROR?) if two packages share nicknames; this is "mostly" the case. The naming scheme is lengthy and - as it was pointed out in the past - kind of "polluting". I still do think it is worth exploring... Note also that I am not suggesting a file system mapping for packages. Having said so, this may be worth a CDR by its own. Yet, maybe this is not the right venue for such discussion. Cheers -- Marco On Apr 26, 2011, at 14:39 , Nikodemus Siivola wrote:
On 26 April 2011 14:31, Didier Verna <didier@lrde.epita.fr> wrote:
Yeah. This is something one needs to do in several occasions already (for instance to get MOP functions from packages named differently across implementations) and I don't think it's such a big deal.
Unless you use CLOSER-MOP. :)
I think a semi-standard package for extensions like this would be good, but that's probably just my idealism speaking.
Cheers,
-- Nikodemus
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Marco Antoniotti
Hi, I think something like :cdrNN as package names (or nicknames thereof) could actually work. I am not very afraid of fragmentation. Newer CDRs that supersede older CDRs can suggest to still use the old package names as well (if they are sufficiently similar enough). There could exist separate CDRs with suggestions for grouping several other CDRs in larger chunks, so you have common package names for a collection of more or less strongly related components. Such a scheme could coexist with a more elaborate naming scheme that focuses on avoiding potential name clashes (although I'm not sure the latter would really pays off). I see a design mistake in Common Lisp's package system in that the nickname is chosen by the package definition, not by the use site (for example as in (:use-package :horribly-long-package-name :as :hlpn)). That's probably harder to fix. Maybe the Pro mailing list is a better venue for discussing such proposals, because that mailing list seems to be frequented by many active users. [These are all my very own, very subjective opinions. The fact that I'm involved in maintaining the CDR repository doesn't mean my opinions have more weight than others. Just to be sure I mentioned that... ;)] Pascal On 28 Apr 2011, at 16:47, Marco Antoniotti wrote:
Hi
packages and extensions are a pet-peeve of mine. :)
I feel strongly on the subject and I have followed the following conventions in my recent coding (conventions which hinge on a non-standard and unadvertised feature of many implementations: see below).
Most of my packages are now named as
"IT.UNIMIB.DISCO.MA.XXX.YYY.ZZZ"
Then they may have nicknames, which can be
"COMMON-LISP.EXTENSIONS.DATA-AND-CONTROL-FLOW.STUFF" and "CL.EXT.DACF.STUFF" and "STUFF".
The naming scheme I adopted for the "COMMON-LISP.EXTENSIONS.CH" packages is that CH is the name of one of the ANSI chapters. Of course, one could imagine a "COMMON-LISP.EXTENSIONS.NETWORKING" package and a "COMMON-LISP.EXTENSIONS.MULTIPROCESSING" package for things which do not appear in the ANSI.
I feel this satisfies my inner need for order.
Two notes:
The whole thing is predicated on an implementation raising an error (a PACKAGE-ERROR?) if two packages share nicknames; this is "mostly" the case. The naming scheme is lengthy and - as it was pointed out in the past - kind of "polluting".
I still do think it is worth exploring... Note also that I am not suggesting a file system mapping for packages.
Having said so, this may be worth a CDR by its own. Yet, maybe this is not the right venue for such discussion.
Cheers -- Marco
On Apr 26, 2011, at 14:39 , Nikodemus Siivola wrote:
On 26 April 2011 14:31, Didier Verna <didier@lrde.epita.fr> wrote:
Yeah. This is something one needs to do in several occasions already (for instance to get MOP functions from packages named differently across implementations) and I don't think it's such a big deal.
Unless you use CLOSER-MOP. :)
I think a semi-standard package for extensions like this would be good, but that's probably just my idealism speaking.
Cheers,
-- Nikodemus
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Marco Antoniotti
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Hello yes, of course. Having the CDRNN naming is fine with me as well. It would work well with any other naming scheme. Plus, if I remember each implementation implementing a CDR is encouraged to push :cdrNN in *FEATURES*. Just a question. What is the Pro mailing list? Marco On Apr 28, 2011, at 21:51 , Pascal Costanza wrote:
Hi,
I think something like :cdrNN as package names (or nicknames thereof) could actually work. I am not very afraid of fragmentation. Newer CDRs that supersede older CDRs can suggest to still use the old package names as well (if they are sufficiently similar enough). There could exist separate CDRs with suggestions for grouping several other CDRs in larger chunks, so you have common package names for a collection of more or less strongly related components.
Such a scheme could coexist with a more elaborate naming scheme that focuses on avoiding potential name clashes (although I'm not sure the latter would really pays off).
I see a design mistake in Common Lisp's package system in that the nickname is chosen by the package definition, not by the use site (for example as in (:use-package :horribly-long-package-name :as :hlpn)). That's probably harder to fix.
Maybe the Pro mailing list is a better venue for discussing such proposals, because that mailing list seems to be frequented by many active users.
[These are all my very own, very subjective opinions. The fact that I'm involved in maintaining the CDR repository doesn't mean my opinions have more weight than others. Just to be sure I mentioned that... ;)]
Pascal
On 28 Apr 2011, at 16:47, Marco Antoniotti wrote:
Hi
packages and extensions are a pet-peeve of mine. :)
I feel strongly on the subject and I have followed the following conventions in my recent coding (conventions which hinge on a non-standard and unadvertised feature of many implementations: see below).
Most of my packages are now named as
"IT.UNIMIB.DISCO.MA.XXX.YYY.ZZZ"
Then they may have nicknames, which can be
"COMMON-LISP.EXTENSIONS.DATA-AND-CONTROL-FLOW.STUFF" and "CL.EXT.DACF.STUFF" and "STUFF".
The naming scheme I adopted for the "COMMON-LISP.EXTENSIONS.CH" packages is that CH is the name of one of the ANSI chapters. Of course, one could imagine a "COMMON-LISP.EXTENSIONS.NETWORKING" package and a "COMMON-LISP.EXTENSIONS.MULTIPROCESSING" package for things which do not appear in the ANSI.
I feel this satisfies my inner need for order.
Two notes:
• The whole thing is predicated on an implementation raising an error (a PACKAGE-ERROR?) if two packages share nicknames; this is "mostly" the case. • The naming scheme is lengthy and - as it was pointed out in the past - kind of "polluting".
I still do think it is worth exploring... Note also that I am not suggesting a file system mapping for packages.
Having said so, this may be worth a CDR by its own. Yet, maybe this is not the right venue for such discussion.
Cheers -- Marco
On Apr 26, 2011, at 14:39 , Nikodemus Siivola wrote:
On 26 April 2011 14:31, Didier Verna <didier@lrde.epita.fr> wrote:
Yeah. This is something one needs to do in several occasions already (for instance to get MOP functions from packages named differently across implementations) and I don't think it's such a big deal.
Unless you use CLOSER-MOP. :)
I think a semi-standard package for extensions like this would be good, but that's probably just my idealism speaking.
Cheers,
-- Nikodemus
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Marco Antoniotti
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
-- Marco Antoniotti
Marco Antoniotti wrote:
Just a question. What is the Pro mailing list?
http://common-lisp.net/pipermail/pro/2010-September/000005.html Arthur
participants (5)
-
Arthur Lemmens -
Didier Verna -
Marco Antoniotti -
Nikodemus Siivola -
Pascal Costanza