- cdr-discuss - mailman3.common-lisp.net

CDR for Package-Local Nicknames [Feedback Request]
by Alexander Fedorov 06 Jul '24

06 Jul '24

Dear all, Over 10 years ago, SBCL implemented the Package-Local Nicknames (PLNs) extension. Since then, PLNs have also been adopted by multiple implementations (ABCL, CCL, ECL, Clasp, Allegro CL and LispWorks) and are now widely used in many projects. However, PLNs are still considered experimental, as stated in the SBCL manual, since there is no formal specification for them, and each implementation interprets various corner cases differently. While the need for a specification has been previously discussed, I was unable to find any publicly accessible draft for one. Therefore, I have drafted a specification intended to become a CDR document. I initially wrote this draft about a year ago and have recently revised it. You can find the latest version here: https://gleefre.github.io/cdr-package-local-nicknames/index.html. There are currently nine unresolved standardization issues, each with at least one proposed resolution. Input on those issues would be particularly helpful, but any feedback is welcome! P.S. I am sharing this link across multiple platforms to reach as many lispers as possible. This includes various mailing lists (Lisp Pro, CDR-discuss and -devel for various CL implementations); IRC channels (#commonlisp and implementation-specific ones); the Lisp Discord server; several Telegram groups; and a post on Reddit. If you have any suggestions for additional places to share the link, please let me know. My apologies to those receiving this message multiple times. Best regards, Alexander Fedorov.

1 0

CDR for Package-Local Nicknames [Feedback Request]
by Alexander Fedorov 06 Jul '24

06 Jul '24

Dear all, Over 10 years ago, SBCL implemented the Package-Local Nicknames (PLNs) extension. Since then, PLNs have also been adopted by multiple implementations (ABCL, CCL, ECL, Clasp, Allegro CL and LispWorks) and are now widely used in many projects. However, PLNs are still considered experimental, as stated in the SBCL manual, since there is no formal specification for them, and each implementation interprets various corner cases differently. While the need for a specification has been previously discussed, I was unable to find any publicly accessible draft for one. Therefore, I have drafted a specification intended to become a CDR document. I initially wrote this draft about a year ago and have recently revised it. You can find the latest version here: https://gleefre.github.io/cdr-package-local-nicknames/index.html. There are currently nine unresolved standardization issues, each with at least one proposed resolution. Input on those issues would be particularly helpful, but any feedback is welcome! P.S. I am sharing this link across multiple platforms to reach as many lispers as possible. This includes various mailing lists (Lisp Pro, CDR-discuss and -devel for various CL implementations); IRC channels (#commonlisp and implementation-specific ones); the Lisp Discord server; several Telegram groups; and a post on Reddit. If you have any suggestions for additional places to share the link, please let me know. My apologies to those receiving this message multiple times. Best regards, Alexander Fedorov.

1 0

Test
by Marco Antoniotti 04 Jan '22

04 Jan '22

Please ignore... -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

1 0

CDR Community on Zenodo.org
by Marco Antoniotti 13 Sep '19

13 Sep '19

Dear all I took the liberty to create a Zenodo Community for CDRs (https://zenodo.org/communities/cdr/) The main advantage of the Zenodo setup is that it assigns DOIs to he uploaded documents. In that way each CDR can also be cited in an unambiguous way across the Internet. If it is ok with all the submitters I will (slowly) upload the CDRs to the Zenodo Community with all the appropriate attributions. If you feel that something should not be uploaded or if you think there may be some problems with its uploading, do let me know. For the time being I will not upload the CLOS CDR as there may be some issue with it, although it is probably not that important anymore. Cheers MA -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

3 4

Test: ignore
by Marco Antoniotti 12 Sep '19

12 Sep '19

Please ignore…. -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0

Discoverability of CDR implementations (pre-submission discussion)
by Michael Raskin 26 Jun '19

26 Jun '19

Ooops, sorry, sent to the wrong list. Forwarding to the correct one. >>>> Hello I was told that it might be better to have a separate document about interaction of CDRs and packages. I think as the problem with packages for CDR-defined symbols is about discoverability and probing, it is a good idea to also provide some functionality for probing for available but not loaded CDR implementations. The draft is currently available at: https://gitlab.common-lisp.net/mraskin/cdr-walkability/blob/master/cdr-pack… It is also attached as a text file to this message All feedback is of course very welcome. Thank you, goodbye Michael Raskin

3 5

CDR-14 and optional modules
by Michael Raskin 26 May '19

26 May '19

Hello I look at CDR-14 that says about putting :CDR-NN symbols into *features* if implementation purports to implement a CDR. What is the recommended behaviour in the case when the implementation provides a loadable module to support a CDR? Should the feature be always present or only appear when the module is loaded? What are the opinions? Thank you, good bye Michael Raskin

2 2

Pre-submission discussion: code walking
by Michael Raskin 12 May '19

12 May '19

Hello. I want to try to do something about portability of universally present features, given that stndard revisions are extremely unlikely, and CDR process seems to be the best way to obtain a stable ID for some version of description. As automatic code processing is a large part of Common Lisp identity as it is presented, and there is a small and easy to define chunk of functionality that is missing, I am preparing a CDR on portable code walking support. Before I formally submit a CDR proposal, I want to try to get some feedback. The current version of the writeup I have is at: https://gitlab.common-lisp.net/mraskin/cdr-walkability/blob/master/walkabil… Please comment on that proposal, here or via issues or maybe even merge requests. I will announce the link to the discussion in the ELS mailing list (as ELS conference seems to be the closest approximation to community discussion we have). I considered including Trucler API as an option, but currently I doubt I am able to do it well: mixing a coherent API with multiple optional additions that are useful even as single functions is a harder task. I want to start somewhere. Separately, if someone has some proposals on how to make CDR process used more — or matter more, please share. Probably on cdr-devel https://mailman.common-lisp.net/listinfo/cdr-devel Thank you, goodbye Michael Raskin

4 11

Re: Pre-submission discussion: code walking
by Daniel Kochmański 26 Apr '19

26 Apr '19

sorry, replied directly instead to the group. forwarding to the ml. On Fri, 2019-04-26 at 14:04 +0200, Daniel Kochmański wrote: > > This has been discussed before and it was not quite deemed a very > > useful approach, as it would mean that you would have single > > namespace where different implementations of a given CDR would be > > dumped, possibly causing unwanted misalignments. > > If something may be implemented as a library (i.e doesn't require > special interfaces provided by the implementation) it might be > arguable > if it is a useful as a "standard extension" instead of a "library > with > documented protocol".

2 1

Re: CDR maintenance
by Antoniotti Marco 25 May '18

25 May '18

IMHO it is a chicken and egg problem. E.g., having the MOP document in a clear and stable place has worked as a nudge for the implementations. But the main issue is that writing quality spec documents is hard and it takes time, therefore YMMV etc etc. Again, the process is very simple and, alas, pretty dead. I would welcome a CDR on UIOP, but IMHO it will be quite a bit of work as UIOP is rather large. And then there are other interesting issue, such as the recent snag on READER-ERROR and PACKAGE-ERROR discussed on CLL. Things like this do require implementors’ commitment, but, as we all know this discussion has been going on for years at this point. Cheers — MA > On May 24, 2018, at 23:33 , Stelian Ionescu <sionescu(a)cddr.org> wrote: > > Sure, but I'm afraid that the problem with CDR process is that if you don't get buy-in from implementors first, it will go nowhere. Right now the CDR repository is mostly a dump for half-baked ideas. Is there even one that has been adopted by at least two CL implementations *after* publication ? > > > >> It might be nice to get some of the APIs that are in UIOP into CDRs. I'd love to see some of that code moved to the implementations where it belongs, and out of the ASDF codebase. >> >> >> cheers, >> r >> >> >> On 24 May 2018, at 3:34, Antoniotti Marco wrote: >> >> >> >>> On May 23, 2018, at 11:57 , Svante v. Erichsen <Svante.v.Erichsen(a)web.de> wrote: >>> >>> Hi >>> >>> I agree that hosting seems not to be the issue. It just needs to be corrected in CDR 4 (adjusting URLs is allowed). >> >> Yep.. That should be fixed. >> >>> I was just asking about the existing procedure, in whatever state that may be, as I am considering participation. Of course, this should be taken to the CDR mailinglists instead, sorry for that. >> >> The procedure is quite simple. I quote: >> >> • One or more authors submit a document. >> • We (*) check that the document is a printable text document, that it is indeed about Common Lisp, and that it does not contain objectionable material (like porn, religious or political statements, etc.). >> • The document will be immediately assigned a fresh CDR number that can be used to refer to the document. We will make the document available for an initial period, after which it will be frozen and moved into final status, unless the authors decide to withdraw the document during the initial period. >> >> (*) the “editors” >> >> Apart from my guilty delinquency on redoing the web site, most of the work has been taking care of spam (an inordinate amount of French spam - go figure) on the mailing lists. >> >> >>> I disagree about the judgement of the perceived lack of contributions, though. I feel that it is perfectly valid not to have itches that would need to be scratched on the language level. >> >> Of course. I do not think that any of the 14 CDRs “scratch itches at the language level”. >> >> Having said so, I do believe that a few more CDRs would go a long way to clarify the corner cases of the language while nudging all the implementations (if they are “nudge-able”) to implement them. >> >> Cheers >> — >> MA >> >> >> >> >> >> >> >> >> >> >> >>> >>> Yours aye >>> >>> Svante >>> >>> Am 23. Mai 2018 08:40:14 MESZ, schrieb Antoniotti Marco <antoniotti.marco(a)disco.unimib.it>: >>> >>>> Hi >>>> >>>> I don’t think the problem is the hosting; CLL works just fine and CDR >>>> hold only “finished” documents. I think that the main problem is the >>>> *lack* of contributions, which somehow reflects the overall status of >>>> the community. >>>> >>>> How to change the attitude of the community into seeing value in what >>>> is in effect a “bottom up” standardization effort, I sincerely don’t >>>> know. >>>> >>>> Cheers >>>> — >>>> MA >>>> >>>> >>>> >>>> >>>> >>>>> On May 22, 2018, at 13:14 , Alexandre Rademaker >>>> <arademaker(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> Back in 2013, ECL in Madrid, I remember some discussions about the >>>> future of CDR. It would be nice to compare with other similar >>>> initiatives such as >>>> >>>>> >>>>> Python :https://www.python.org/dev/peps/ >>>>> Erlang : http://www.erlang.org/erlang-enhancement-proposals/home >>>>> >>>>> I’ve also tried to see how Haskell and Racket deal with that. I found >>>> this https://www.quora.com/Is-there-anything-like-PEP-but-for-Haskell >>>> about Racket. Racket seems to use Github issues >>>> https://github.com/racket/racket/issues >>>> >>>>> >>>>> Is there still a place for CDR? If so, maybe we can simply use the >>>> GitHub infrastructure? We may also try to find incentives to CDR >>>> submissions? Maybe associating it to short-papers in ECL/ECLM? >>>> >>>>> >>>>> Best, >>>>> >>>>> -- >>>>> Alexandre Rademaker >>>>> http://arademaker.github.io >>>>> >>>>> >>>>> >>>>>> On 22 May 2018, at 06:53, Antoniotti Marco >>>> <antoniotti.marco(a)disco.unimib.it> wrote: >>>> >>>>>> >>>>>> Hi >>>>>> >>>>>> I have been somewhat stewarding the project, but do not have much >>>> time to do maintenance (read: revamping the web site) at all. >>>> >>>>>> >>>>>> It must also be said that there have not been submissions for CDRs, >>>> or requests for much change to old ones in a long time as far as I >>>> could tell. >>>> >>>>>> >>>>>> All the best >>>>>> >>>>>> Marco >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On May 22, 2018, at 11:43 , Svante v. Erichsen >>>> <Svante.v.Erichsen(a)web.de> wrote: >>>> >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> I'd certainly want this project to continue, so I'd consider >>>> participating in it. Can you give a rough estimate of the frequency of >>>> requests and the effort needed to address them? >>>> >>>>>>> >>>>>>> I am a bit confused that the project actually seems to reside at >>>> common-lisp.net, but claims to be hosted at cdr.eurolisp.org (which >>>> redirects to Edi's homepage). How is the work organized technically? Is >>>> there a version control repository? >>>> >>>>>>> >>>>>>> Yours aye >>>>>>> >>>>>>> Svante >>>>>>> >>>>>>> Am 22. Mai 2018 10:50:20 MESZ, schrieb Pascal Costanza >>>> <pc(a)p-cos.net>: >>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> The Common Lisp Document Repository (CDR - >>>>>>>> https://common-lisp.net/project/cdr/) is for all practical >>>> purposes >>>> >>>>>>>> currently unmaintained. We have been receiving a few minor >>>> requests >>>> >>>>>>>> recently, but don’t have the time anymore to take care of this. >>>>>>>> >>>>>>>> Is there somebody else in the community who would like to take >>>> over and >>>> >>>>>>>> breathe some new life into this project? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pascal >>>>>>>> >>>>>>>> -- >>>>>>>> Pascal Costanza >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 >>>>>> DISCo, Università Milano Bicocca U14 >>>> 2043 http://bimib.disco.unimib.it >>>> >>>>>> Viale Sarca 336 >>>>>> I-20126 Milan (MI) ITALY >>>>>> >>>>>> Please check: http://cdac2018.lakecomoschool.org >>>>>> Please check: http://troncopackage.org >>>>>> Please check: >>>> https://www.frontiersin.org/research-topics/7394/network-bioscience >>>> >>>>>> >>>>>> Please note that I am not checking my Spam-box anymore. >>>>>> Please do not forward this email without asking me first (cum grano >>>> salis). >>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 >>>> DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it >>>> Viale Sarca 336 >>>> I-20126 Milan (MI) ITALY >>>> >>>> Please check: http://cdac2018.lakecomoschool.org >>>> Please check: http://troncopackage.org >>>> Please check: >>>> https://www.frontiersin.org/research-topics/7394/network-bioscience >>>> >>>> Please note that I am not checking my Spam-box anymore. >>>> Please do not forward this email without asking me first (cum grano >>>> salis). >>> >>> >> >> -- >> Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 >> DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it >> Viale Sarca 336 >> I-20126 Milan (MI) ITALY >> >> Please check: http://cdac2018.lakecomoschool.org >> Please check: http://troncopackage.org >> Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience >> >> Please note that I am not checking my Spam-box anymore. >> Please do not forward this email without asking me first (cum grano salis). >> >> >> >> >> >> >> >> >> Robert P. Goldman >> Research Fellow >> Smart Information Flow Technologies (d/b/a SIFT, LLC) >> >> >> 319 N. First Ave., Suite 400 >> Minneapolis, MN 55401 >> >> >> Voice: (612) 326-3934 >> Email: rpgoldman(a)SIFT.net >> > > > -- > Stelian Ionescu a.k.a. fe[nl]ix > Quidquid latine dictum sit, altum videtur. -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2018.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0