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

Re: CDR maintenance
by Antoniotti Marco 24 May '18

24 May '18

On May 23, 2018, at 11:57 , Svante v. Erichsen <Svante.v.Erichsen(a)web.de<mailto:Svante.v.Erichsen@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<mailto:antoniotti.marco@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<mailto:arademaker@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).

1 0

CDR-8 and hash tables
by Anticrisis 09 Sep '17

09 Sep '17

Greetings, I feel timid sending this email to this list given that it’s been dormant since 2014. But after a few queries on #lisp, no better place was offered, and the currently-published information on CDRs directs readers to this list. Here is the substance of my inquiry: I believe CDR-8’s specification of EQUALS with respect to hash tables is incomplete, and its design may lead to some confusion. Here is an example, which uses an implementation of EQUALS provided by the library :generic-comparability[1]: CL-USER> (ql:quickload :generic-comparability) (:GENERIC-COMPARABILITY) CL-USER> (defvar a (make-hash-table :test 'equalp)) A CL-USER> (defvar b (make-hash-table :test 'equalp)) B CL-USER> (setf (gethash "x" a) 1) 1 CL-USER> (setf (gethash "X" b) 1) 1 CL-USER> (loop for k being the hash-keys in a always (eql (gethash k a) (gethash k b))) T CL-USER> (generic-comparability:equals a b) NIL Here we see EQUALS disagreeing with a GETHASH-based equality test[2], which CDR-8 might argue is by design. EQUALS is its own equality test, so it should override whatever is set in the hash table it’s given. However, the spec is not explicit on this point, which may be surprising to the unsuspecting programmer. Moreover, let’s continue: let’s assume the :by-key argument to EQUALS is NIL, so the request is to compare only the hash table values. Well, the only way to correctly compare the values in two tables is to arrange them by their keys, and then compare them. To do otherwise would be meaningless. But what function should be used to arrange the keys? If EQUALS is used, then the result will be identical to :by-key T, and will be inconsistent with an EQUALP hash-table as per my example. It would seem more appropriate to use the function designated by HASH-TABLE-TEST, but CDR-8 is silent on this question, which makes the specification incomplete. A secondary problem with CDR-8 is in the example implementation given for hash tables. The LOOP presented implicitly depends on HT-KEYS returning keys in some sort of consistent, total ordering, because otherwise it would be meaningless to do a key-wise comparison. However, the spec is silent on this requirement. And it’s not obvious what comparison function CDR-8 would prefer: its own COMPARE, or the user-specified HASH-TABLE-TEST function. In practice, at least under SBCL, iterating through a hash table with LOOP will generate the keys in a different order depending on their insertion order. (I believe the order in which hash table keys are iterated is unspecified in the standard.) Furthermore, it seems nonsensical to provide for disjoint comparison of keys and values. For example, should a test of the form (EQUALS (:a 1 :b 2) (:a 2 :b 1) :by-keys T :by-value NIL) return T, and (... :by-keys NIL :by-value T) also return T? The most common case for comparing hash tables is to ensure they have the same number of keys, that the set of keys in each table are equal, and that the values in the slots referred to by the keys are also equal. The proposed implementation does not provide this. I hope this exposition is helpful. I’d accept any suggestions on how to help improve CDR-8 or :generic-comparability. Best, anticrisis [1] https://github.com/pnathan/generic-comparability [2] Looping through the keys of A is only part of the equality test. Not shown is checking the other hash table properties, in particular, the hash table test function, as returned by HASH-TABLE-TEST.

2 1

[CDR-discuss] CDRs on arXiv
by Antoniotti Marco 08 May '14

08 May '14

Dear all, I thought that a good idea to generate some interest in the community would be to publish all the finalized CDRs on arXiv. To this end it would be useful if all the past CDR contributors would take the time to prepare an ‘arXiv’ acceptable submission and let the editors know that they have done so. All the best -- 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 note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

1 0

[Cdr-discuss] Test....
by Antoniotti Marco 06 Apr '14

06 Apr '14

…. please … ignore…. 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 note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

1 0

[cdr-discuss] Re: Detecting implementations of CDR specifications...
by Marco Antoniotti 11 Jun '13

11 Jun '13

On Jun 11, 2013, at 24:47 , Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: > Antoniotti Marco > <antoniotti.marco(a)disco.unimib.it> writes: > >> Dear all, >> >> following up the CDR discussion that took place aside the European >> Lisp Symposium in Madrid a week ago, I prepared this document that >> specifies how a CL environment can test for the "presence" of a given >> CDR. >> >> I wanted to pass it around before submitting it formally to the CDR >> editors. > > 1) > > Specify what format 'n' has: the number of the CDR, represented in base > ten without leading 0s. Good point. > > 2.1.2) > > If multiple implementations of a given CDR are expected, perhaps we > should have keywords such as: :LISP=CL :BASE-CHAR=CHARACTER or > :WORD-SIZE=64 on *features*, so we could have: > > CDR-{n}={implementation-identifier} > > > > #+CDR-{n}=com.informatimago.common-lisp.cdr-{n} > (com.informatimago.common-lisp.cdr-{n}:stuff) > > #+CDR-{n}=alexandria > (alexandria:stuff) > > #-CDR-{n} > (do-my-own-stuff) > > > So specify 2) that implementations of CDRs should do two things: > > (pushnew :cdr-{n} *features*) > (push :cdr-{n}={implementation-identifier} *features*) This is interesting, but I am afraid it introduces a source of extra variability. I am assuming that a CDR should represent a "state of affairs" that is already agreed upon. In any case, I think this can go in a subsequent CDR. > 2.1.3) > > The absence of :cdr-{i} doesn't let infer anything about the present or > absent of CDRs from *features*. The presence of :cdr-{n} should imply > the presence of :cdr-{i}. What the presence of :cdr-{i} tells us, is > the meaning of the absence of :cdr-{n}: it means the CDR is not > implemented. > > > So: > > #+(AND CDR-{i} CDR-{n}) should be equivalent in meaning to > #+CDR-{n} and means CDR-{n} is present (definitely). > > #+(AND CDR-{i} (not CDR-{n})) means CDR-{n} is absent (definitely). > > #-(and CDR-{i} CDR-{n}) is equivalent to > #+(or (not CDR-{i}) (not CDR-{n})) which is not helpful: > > - CDR-{n} could implemented, but just :cdr-{n} not on > *features*, which is possible since CDR-{i} is not > implemented. > > - CDR-{n} could be not implemented, and therefore :cdr-{n} > is rightly not on *features*. > > > #-(and CDR-{i} (not CDR-{n})) is equivalent to > #+(or (not CDR-{i}) CDR-{n}) which may mean that: > either > cdr-{i} is absent and cdr-{n} is absent (see above) > or cdr-{i} is absent and cdr-{n} is present, in case cdr-{n} is > implemented, but not cdr-{i}, > or cdr-{i} is present and cdr-{n} is present (see first case). > But the condition doesn't let us distinguish. > > In conclusion, the only interesting expressions are: > > #+cdr-{i} (is-implemented CDR-{i}) > #-cdr-{i} (is-not-implemented CDR-{i}) > > #+cdr-{n} (is-implemented CDR-{n}) > #+(and cdr-{i} (not cdr-{n})) (is-not-implemented CDR-{n}) > #+(and (not cdr-{i}) (not cdr-{n})) (we-don-t-know-anything) I take you are referring to the :CDR-i where 'i' is the one that may be assigned to the proposal. Yes. All you say is fine. Cheers -- Marco Antoniotti

1 0

[cdr-discuss] ECLM and ELS 2013 -- CDR Meeting?
by Marco Antoniotti 06 Jun '13

06 Jun '13

Hi how about setting up an "official" CDR meeting at ECLM and ELS 2013? Just an idea…. -- Marco Antoniotti

7 12

Re: [cdr-discuss] [cdr-announce] CDR 12 withdrawn
by Pascal Costanza 02 Jan '13

02 Jan '13

[forwarded to cdr-discuss] On 2 Jan 2013, at 04:44, Steve Haflich <smh(a)franz.com> wrote: > A tangential comment: > > If this CDR is ever resumitted, I suggest the title should be revised. > The word "heap" is heavily overloaded with other meanings in Lisp > technology. Its here use misled me initially. > > _______________________________________________ > cdr-announce mailing list > cdr-announce(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cdr-announce -- Pascal Costanza

1 0

Re: [cdr-discuss] [cdr-announce] CDR 12 accepted
by Marco Antoniotti 29 Dec '12

29 Dec '12

Hi The PDF is broken. We need a fixed spec to properly discuss it. MA On Nov 20, 2012, at 20:55 , Pascal Costanza <pc(a)p-cos.net> wrote: > The document "Generic extendable heaps for Common Lisp" has been submitted by Ingvar Mattsson and has been accepted as CDR document 12. According to the CDR process, this document is now in its initial stage and will be finalized on January 1, 2012, unless withdrawn by the author beforehand. See http://cdr.eurolisp.org/document/12/ for the details of this document. > > -- > Pascal Costanza > > > > > _______________________________________________ > cdr-announce mailing list > cdr-announce(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cdr-announce -- Marco Antoniotti

4 15

Re: [cdr-discuss] [cdr-announce] CDR 11 accepted
by Pascal Costanza 10 Jun '12

10 Jun '12

Hi Steve, Thanks a lot indeed for your interest in CDR. The rationale for CDR is explained at http://cdr.eurolisp.org/ on the opening page. You should find all answers to the question you posted on that page. But let me stress a few points directly related to your questions: - It is certainly possible to discuss a CDR after it has been finalized. - More specifically, it's also certainly possible to refine a CDR after it has been finalized. However, the particular CDR (with a specific CDR number) cannot be changed anymore. If you want to refine a finalized CDR, you have to submit a new one, which will then receive a new CDR number. New CDRs can claim to updates to existing CDRs. (For example, it is already the case that CDR 4 is a refinement of CDR 0, and the whole CDR process is currently based on CDR 4 rather than CDR 0.) - Whether a particular CDR is eventually accepted by the community or not is in the hands of the community, not in the hands of the CDR editors. CDR is only a repository for documents, not a body that can enforce or endorse standards. This was an intentional design decision, to avoid the need for CDR editors to judge the contents of CDR documents (which they don't), and to avoid legal implications. - There are three mailing lists associated with CDR: cdr-announce is for announcements, cdr-devel is for discussions about the CDR repository and process itself, and cdr-discuss is for discussions about specific CDRs. If you would like to continue a discussion about CDR itself, please do so on cdr-devel. Didier (the author of CDR 11) seems to be willing to discuss CDR 11 on cdr-discuss, so if you are interested in that, please discuss it there. (Authors are encouraged, but not required to discuss documents. Again, CDR is intentionally a light-weight process: Any requirements imposed on authors would need to be checked, and CDR is designed to require as few checks as possible. That's why documents don't even need to be discussed, because it would be hard to judge what would qualify as a "sufficient" amount of discussion. We believe that members of the community are mature enough to decide for themselves what constitutes a "good" CDR or not.) Again, thanks a lot for your interest. I hope this clarifies your questions. Please feel free to comment or discuss this further, if you think there is room for improvement. Best, Pascal P.S.: I personally believe that Duane Rettig's proposal for environment access would be an excellent candidate for a CDR. Franz Inc. probably has more extensions that would be good contributions. Please let us know if we can help with submitting CDR documents, in case you are interested. On 8 Jun 2012, at 06:49, Steve Haflich wrote: > Pascal et al. > > I'm confused, or perhaps only ignorant, about the process underlying the > CDR repository. Once a CDR becomes final after a very short time, there > seems to be no forum or machinery to discuss or refine it. While I find > myself sympathetic to at least some of the stated problems, none of the > stated solutions are fully acceptable -- there are glitches in the > specifications, or important situations missed, or incompatibilities > between proposed changes and the official sanctity of the CL package. > > Is there some forum for further discussion of "final" CDRs? Otherwise > the CDRs seem a rather profitless exercise. > > _______________________________________________ > cdr-announce mailing list > cdr-announce(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cdr-announce -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

1 0

Re: [cdr-discuss] [cdr-announce] CDR 10 accepted
by Nick Levine 23 May '12

23 May '12

It's not at all clear to me from reading CDR document 10 <http://cdr.eurolisp.org/document/10/compiled-file-p.html> what an ABI version is (as in "the argument identifies an ABI version which can be consumed by the implementation"). Further examples of abi-version (in particular, one which shows a possible input or output value rather than just piping the two together) would make this clearer. - nick

2 2