- iterate-devel - mailman3.common-lisp.net

[iterate-devel] Fwd: using keywords in clauses
by Denis Budyak 22 Oct '12

22 Oct '12

Second reply to Zach which should have been sent to an iterate-devel mailing list too. ---------- Forwarded message ---------- From: Denis Budyak <budden73(a)gmail.com> Date: Tue, 16 Oct 2012 22:15:18 +0400 Subject: Re: [iterate-devel] using keywords in clauses To: Zach <zach.smith(a)colorado.edu> Zach, list, > Why isn't your patch >nothing more than a single file that looks like: >(iterate:defsynonym :for iterate:for) >(iterate:defsynonym :collect iterate:collect) >... >(iterate:defsynonym :appending iterate:appending) >Why isn't this just a small separate library called iterate-keyword >that only exports ITERATE? This is because synonym mechanism is not universal. It doesn't cover cases of iterate:first-time-p, iterate:next-iteration etc. defsynonym simply do not work for them. To make them work, one need to patch iterate itself. > One last thing, I would hope that you wouldn't actually attempt to > patch iterate to not export FOR, WHILE Of course I didn't attempt this. In fact, there is no need to use iterate in any package, if one can use keywords. Just writing (:import-from :iter #:iter) would suffice. > Is the root of your desire to do this the >fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the >same package that you want to use Iterate? Iterate is a very agressive exporter of symbols :) When I started using iterate, I just tried to :use both :iterate and :cl-utilities and this gave me a conflict. One can easily imagine an applicaion (e.g. language parser) where symbols like FOR and WHILE are treated as data and it is desirable for them to come from specific package, not from iterate. Some other person is likely to implement simplified "while" loop. Third person might just try playing with iterate, and she will get conflict in the following innocent lisp session: ; Hallo from your lisp %(in-package :cl-user) %(use-package :iterate) ... conflict ... as FOR might be exported into :cl-user from loop during initialization. > but it would also break any body's code that decided to > (defmacro-clause :for ...) Yes, and it is expected, but sometimes breaking changes occur in a software. > (defun :go ...) defsynonym is not a defun, it only puts a property on a symbol, so the symbol does not change its meaning outside of iterate construct. Just because I agree one should not normally (defun :for), I believe that change proposed is not very harmful as it can be hardly expected that it would break anyone's code. If it is considered a serious threat, we could define *features* member so that iterate could be bulid either with or without keywords support. Unfortunately it seem to be impossible to enable keywords support via a separate library. Regards, Budden

1 0

[iterate-devel] Fwd: using keywords in clauses, reply 1
by Denis Budyak 22 Oct '12

22 Oct '12

Hi list! I see I didn't send my reply to Zach into a iterate-devel mailing list, by omission. I think now it is the time to correct that. ---------- Forwarded message ---------- From: Denis Budyak <budden73(a)gmail.com> Date: Tue, 16 Oct 2012 11:06:34 +0400 Subject: Re: [iterate-devel] using keywords in clauses To: Zach <zach.smith(a)colorado.edu> Hi Zach, list! > If you encode FOR and COLLECT as special tokens that Iterate's > parser/compiler just understands you break the extensibility. Iterate-keywords makes minimal change to iterate. Roughly, it makes (defsynonym :any-clause-head any-clause-head), but only for standard iterate clauses, not for user defined. As synonyms do not work with special clauses like (next-iteration) (it can be considered a bug in synonym mechanism), patch to iterate itself was required. Consequently, it does not break your example. %(iterate-keywors:iter (test:for i in-whole-vector #(1 3)) (:collect i)) (1 3) %(iterate-keywors:iter (:for i in-whole-vector #(1 3)) (:collect i)) ...errs... For is intended to be extensible via second keyword, in-whole-vector in our case. If we define it as in manual, %(in-package :iterate-keywords) %(defmacro-clause (FOR var IN-WHOLE-VECTOR v) ...), It will work with iterate-keywords as intended: %(in-package:cl-user) %(iterate-keywords:iter (:for i in-whole-vector #(1 3)) (:collect i)) (1 3) If we define any new clause, iterate-keywords won't touch it. We can define it in :test package and use the symbol from that package, that is, %(iter (test:our-clause)) Additionally, we can make %(defsynonym :our-clause test:our-clause) and thus enable ourselves to use keyword: %(iter (:our-clause)) > and even then, it would suffer from name collisions inherent in the keyword package Most of iterate keywords are in a keyword package already as they are used in common lisp loop macro. What kind of collision do you mean?

1 0

Re: [iterate-devel] using keywords in clauses
by Zach 21 Oct '12

21 Oct '12

Denis, I got to thinking after I sent the last email and realized that my example was a bit confusing, but you did an excellent job deciphering it. To sum up what it seems you are proposing: Symbols in the iterate package like FOR, WHILE, COLLECT, APPENDING, will be blessed in such a way that they can be accessed via symbols in the keyword package. Writing extensions to Iterate via defmacro-clause and friends will remain the same, it will take a symbol, not a keyword, and will not try to institute the same keyword short cut as the blessed clauses. Is that a fair description? Is the root of your desire to do this the fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the same package that you want to use Iterate? As for your points, I will work backwards: > Most of iterate keywords are in a keyword package already as they are > used in common lisp loop macro. What kind of collision do you mean? People don't usually worry about keyword collisions because keywords act as syntactic markers and do not hold bindings. I am reminded of a recent post by Xach regarding binding certain functions to keywords in your .rc file like... (defun :go (&optional (thing *)) "View THING with some appropriate viewer." ;; On my Mac laptop, I use "open" instead. (sb-ext:run-program "gnome-open" (list (princ-to-string thing)) :search t) thing) These are functions that serve to make the Lisp environment a bit more appealing, not to extend a program's capabilities. This is a fine thing to do right up until the point that someone decides to add these definitions to some utility library. Once that happens, loading that library will clobber any definitions that were in place before. This is an example of how the keyword package is prone to collisions. The collision above is in the space of function definitions, but in Iterate we have a similar space of clauses. Currently those clauses are represented as symbols which afford us all of the protections that the package system gives us to avoid those kinds of collisions. Probably the most confusing thing that my last message did was use the code in the manual dedicated to extending FOR. This made it seem like I was proposing a means that we could extend FOR while I was talking about working within the framework Iterate defines to build a different kind of clause that happens to be named TEST:FOR. Let's say, as a better example, I wanted to define that in my package, that happens to use some data structure that indexes for 1 instead of 0, for loops in iterate are to always default to starting index 1 rather than 0. One way to do this is to define my own clause, FOR that is local to the package and has the exact definition as ITERATE:FOR except that that initial default 0 is turned into a 1. Now I'm not saying that I would ever do this, I'm not saying that this is a good idea, I'm not even saying (now that I see what you are proposing) that I cannot do this with your proposed change in place, but I am saying that the way Iterate is currently set up, INDEX-FROM-ONE:FOR would be on equal syntactic footing as ITERATE:FOR. I do feel that this is an extremely clean mechanism that holds a lot of similarity with standard CL functionality. And with that, I will walk back my objection from, "it might break stuff" to "it isn't necessary and it doesn't look consistent". So I suppose that it is a matter of taste. However, as you pointed out, but I was unaware of, Iterate has defsynonym. Why isn't your patch nothing more than a single file that looks like: (iterate:defsynonym :for iterate:for) (iterate:defsynonym :collect iterate:collect) ... (iterate:defsynonym :appending iterate:appending) Why isn't this just a small separate library called iterate-keyword that only exports ITERATE? Note that including this in Iterate distribution would enable usage of keywords as an alternate syntax for those clauses, drivers, and collectors that happen to have been blessed by Iterate during its creation, but it would also break any body's code that decided to (defmacro-clause :for ...). I'm not sure that this is worth worrying about, but from my point of view this is wrong in the same way someone defining a library that has (defun :go ...) in it is wrong. One last thing, I would hope that you wouldn't actually attempt to patch iterate to not export FOR, WHILE, etc as that really would break code. Zach On Tue, Oct 16, 2012 at 1:06 AM, Denis Budyak <budden73(a)gmail.com> wrote: > Hi Zach, list! >> If you encode FOR and COLLECT as special tokens that Iterate's >> parser/compiler just understands you break the extensibility. > Iterate-keywords makes minimal change to iterate. Roughly, it makes > (defsynonym :any-clause-head any-clause-head), but only for > standard iterate clauses, not for user defined. As synonyms do not > work with special clauses like (next-iteration) (it can be considered a > bug in synonym mechanism), patch to iterate itself was required. > > Consequently, it does not break your example. > %(iterate-keywors:iter (test:for i in-whole-vector #(1 3)) (:collect i)) > (1 3) > > %(iterate-keywors:iter (:for i in-whole-vector #(1 3)) (:collect i)) > ...errs... > > For is intended to be extensible via second keyword, in-whole-vector > in our case. If we define it as in manual, > %(in-package :iterate-keywords) > %(defmacro-clause (FOR var IN-WHOLE-VECTOR v) ...), > It will work with iterate-keywords as intended: > %(in-package:cl-user) > %(iterate-keywords:iter (:for i in-whole-vector #(1 3)) (:collect i)) > (1 3) > If we define any new clause, iterate-keywords won't touch it. > We can define it in :test package and use the symbol > from that package, that is, > %(iter (test:our-clause)) > Additionally, we can make > %(defsynonym :our-clause test:our-clause) > and thus enable ourselves to use keyword: > %(iter (:our-clause)) > >> and even then, it would suffer from name collisions inherent in the keyword package > Most of iterate keywords are in a keyword package already as they are > used in common lisp loop macro. What kind of collision do you mean?

2 2

Re: [iterate-devel] using keywords in clauses
by Zach 16 Oct '12

16 Oct '12

Budden, Like I said, I think we have passed the level of "break someone's (reasonable) code" and is more in the realm of "a matter of taste". It is true that iterate exports many symbols and I believe that I have a vague memory that this was an annoyance long ago, so it might be a hurdle for new users. You in effect have convinced me that it won't be detrimental to me or any hypothetical user I can think of (other than those people that are doing a (defclause :for ...) and they deserve what they get). If the description I gave of the new functionality is accurate, the only issues I still have are: 1. This will discourage new users/developers from writing their own extensions to Iterate, as they will think there is something special about the symbols :FOR, :WHILE, :WITH, etc (and they are special, in that the user cannot write their own just like them). 2. It will make the extensions that are written a little odd looking as they don't keep with the general interface of the abstraction. 3. Given 1 and 2, someone might wonder in the future why there isn't a way to define your own keyword style iterate construct. If this happens we are in the odd position where there are two nearly independent methods of extension in Iterate (both of which is, of course, in addition to the clause overloading that you can do by using DEFCLAUSE with other "keyword specialization" (like the in-whole-vector example in the manual)). As I discussed, one of these methods of extending Iterate is inherently weaker than the other due to name collisions introduced by you. This seems like a real mess to be avoided. These are all social problems, however, not technical. Iterate is something I very much enjoy using and would dislike it if, due to these social problems, extensibility is either weakened, turning Iterate into merely Loop with parentheses, or bifurcated such that extending Iterate is a mess (but a working mess). Of the two, I can deal with messy, inconsistent code. On the idea of backwards compatibility, I would say your change is basically backward compatible and don't worry about *FEATURES*. I would suggest you provide a new package ITERATE-KEYWORDS that only exports ITER and ITERATE but keep the ITERATE package exports the same. Just my opinion and I think this is what you already intend to do. As to the matter of taste, you argue that this is annoying to use the Iterate package as other packages define and export the symbols FOR or WHILE. This is true across all of Common Lisp and we have ways of dealing with it (i.e. shadowing, giving the full package qualified name). It is certainly annoying when it comes up, but I think you wouldn't argue that we should remedy package collisions by interning one package's exported symbols to some other unrelated package (say the keyword package) and modify the Lisp eval function to map those references to the correct package. Other than the fact that with Iterate we have the means to modify the Lisp eval function portably and safely (a macro environment) I'm not sure I see how this is very different. So, I'm not sure this is "the right thing to do," but I am also sympathetic to the fact that symbol name collisions can be irritating when you want to use multiple packages. In case it is not entirely clear, I am not the Iterate maintainer, nor a developer on the Iterate project at all. I am just writing this as a party with a vested interest. The silence of the maintainer is a bit troublesome, though. Zach On Tue, Oct 16, 2012 at 12:15 PM, Denis Budyak <budden73(a)gmail.com> wrote: > Zach, list, >> Why isn't your patch >>nothing more than a single file that looks like: >>(iterate:defsynonym :for iterate:for) >>(iterate:defsynonym :collect iterate:collect) >>... >>(iterate:defsynonym :appending iterate:appending) >>Why isn't this just a small separate library called iterate-keyword >>that only exports ITERATE? > This is because synonym mechanism is not universal. It doesn't cover > cases of iterate:first-time-p, iterate:next-iteration etc. defsynonym > simply do not work for them. To make them work, one need to patch > iterate itself. > >> One last thing, I would hope that you wouldn't actually attempt to >> patch iterate to not export FOR, WHILE > Of course I didn't attempt this. In fact, there is no need to use iterate > in any package, if one can use keywords. Just writing > (:import-from :iter #:iter) > would suffice. > >> Is the root of your desire to do this the >>fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the >>same package that you want to use Iterate? > Iterate is a very agressive exporter of symbols :) When I started > using iterate, > I just tried to :use both :iterate and :cl-utilities and this gave me > a conflict. > One can easily imagine an applicaion (e.g. language parser) where > symbols like FOR and WHILE are treated as data and it is desirable > for them to come from specific package, not from iterate. > > Some other person is likely to implement simplified "while" loop. Third > person might just try playing with iterate, and she will get conflict > in the following innocent lisp session: > > ; Hallo from your lisp > %(in-package :cl-user) > %(use-package :iterate) > ... conflict ... > as FOR might be exported into :cl-user from loop during initialization. > >> but it would also break any body's code that decided to >> (defmacro-clause :for ...) > Yes, and it is expected, but sometimes breaking changes occur > in a software. >> (defun :go ...) > defsynonym is not a defun, it only puts a property on a symbol, > so the symbol does not change its meaning outside of iterate construct. > > Just because I agree one should not normally (defun :for), > I believe that change proposed is not very harmful as it can be hardly > expected that it would break anyone's code. > > If it is considered a serious threat, we could define *features* member > so that iterate could be bulid either with or without keywords support. > Unfortunately it seem to be impossible to enable keywords support > via a separate library. > > Regards, Budden

1 0

[iterate-devel] using keywords in clauses
by Denis Budyak 14 Oct '12

14 Oct '12

Hi list! Some time ago I've suggested that one can use keywords in clauses, e.g. (iter (:for i :from 1 to 10)) instead of (iter (for i from 1 to 10)) This way, one have to import just one symbol iter:iter into her package to use iterate. I made a patch and sent it to this mailing list, but it didn't pass through, maybe due to size limitations or by some other reason. After that, I created a fork, http://sourceforge.net/projects/iteratekeywords/ but several commits were made to iterate since that and my code seem to be outdated. I suggest re-doing my changes so that they could be merged into main iterate repository. But before doing that I'd like to see explicit confirmation that my changes will be accepted (patch is very big and contains about hundred of changes).

2 1

[iterate-devel] iterate tests regression on SBCL 1.0.54 (quicklisp 2012-04-07 vs 2012-03-07): handler-bind.1
by Anton Vodonosov 11 May '12

11 May '12

Iterate test suite shows regression between quicklisp 2012-03-07 and quicklisp 2012-04-07. sbcl-1.0.54.84.mswinmt.1137-215bdc8-win-x64. Test logs: quicklisp 2012-03-07: http://cl-test-grid.appspot.com/blob?key=AMIfv94-RAJv0FSm0WjXUTgYha9U7tUSAz… failed tests: NONE quicklisp 2012-04-07: http://cl-test-grid.appspot.com/blob?key=53022 failed tests: bug/walk.2 As you see, new failure is bug/walk.2.

4 8

[iterate-devel] Bug: "collect at beginning" ignores specified sequence type
by Ilya Perminov 09 May '12

09 May '12

Hi, I reported this bug a few years ago, but it is still there. If both AT BEGINNING and RESULT-TYPE are specified, RESULT-TYPE is ignored. Example: (iter (for i below 2) (collect i at beginning result-type vector)) returns (1 0). Can someone with write access to the darcs repository fix the bug please. My previous report includes a patch: http://www.mail-archive.com/iterate-devel@common-lisp.net/msg00142.html Thanks, Ilya

2 1

[iterate-devel] iterate tests regression on ACL linux 64 (quicklisp 2012-04-07 vs 2012-03-07): handler-bind.1
by Anton Vodonosov 06 May '12

06 May '12

Iterate test suite shows regression between quicklisp 2012-03-07 and quicklisp 2012-04-07. acl-8.2a-linux-x64. Test logs: quicklisp 2012-03-07: http://cl-test-grid.appspot.com/blob?key=AMIfv97pKvcGKmd6_yqeRupJ3ii6PsLmOu… failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected quicklisp 2012-04-07: http://cl-test-grid.appspot.com/blob?key=20006 failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected handler-bind.1 As you see, new failure is handler-bind.1.

1 0

[iterate-devel] ELS 2012, Zadar, Croatia
by Marco Antoniotti 01 Feb '12

01 Feb '12

Apologies for the multiple postings. PAPER SUBMISSION DEADLINE EXTENDED European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 http://european-lisp-symposium.org The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2012 European Lisp Conference is "Interoperability: Systems, Libraries, Workflows". Lisp based and functional-languages based systems have grown a variety of solutions to become more and more integrated with the wider world of Information and Communication Technologies in current use. There are several dimensions to the scope of the solutions proposed, ranging from "embedding" of interpreters in C-based systems, to the development of abstractions levels that facilitate the expression of complex context dependent tasks, to the construction of exchange formats handling libraries, to the construction of theorem-provers for the "Semantic Web". The European Lisp Symposium 2012 solicits the submission of papers with this specific theme in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: February 15th 2012: submission deadline (extended deadline) March 7th 2012: acceptance results April 30th 2012: Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: Damir Cavar, Eastern Michigan University Franjo Pehar, University of Zadar Damir Kero, University of Zadar Members: Giuseppe Attardi, Università degli Studi di Pisa, Pisa, ITALY Pascal Costanza, Intel, Bruxelles, BELGIUM Marc Feeley, Université de Montreal, Montreal, CANADA Scott McKay, Google, U.S.A. Kent Pitman, U.S.A. Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM Robert Strandh, LABRI, Université de Bordeaux, Bordaux, FRANCE Didier Verna, EPITA / LRDE, FRANCE Taiichi Yuasa, Kyoto University, JAPAN -- Marco Antoniotti

1 0

[iterate-devel] ELS2012 Zadar, Croatia, Call for Papers
by Marco Antoniotti 23 Jan '12

23 Jan '12

Apologies for the multiple postings... =========================================================================== European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 http://european-lisp-symposium.org The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2012 European Lisp Conference is "Interoperabilty: Systems, Libraries, Workflows". Lisp based and functional-languages based systems have grown a variety of solutions to become more and more integrated with the wider world of Information and Communication Technologies in current use. There are several dimensions to the scope of the solutions proposed, ranging from "embedding" of interpreters in C-based systems, to the development of abstractions levels that facilitate the expression of complex context dependent tasks, to the construction of exchange formats handling libraries, to the construction of theorem-provers for the "Semantic Web". The European Lisp Symposium 2012 solicits the submission of papers with this specific theme in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: Jan 31st 2012: submission deadline Feb 21st 2012: acceptance results April 30th, 2012 Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: Damir Ćavar, Eastern Michigan University Franjo Pehar, University of Zadar Damir Kero, University of Zadar Members: Giuseppe Attardi, Università degli Studi di Pisa, Pisa, ITALY Pascal Costanza, Intel, Bruxelles, BELGIUM Marc Feeley, Université de Montreal, Montreal, CANADA Scott McKay, Google, U.S.A. Kent Pitman, U.S.A. Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM Robert Strandh, LABRI, Université de Bordeaux, Bordaux, FRANCE Didier Verna, EPITA / LRDE, FRANCE Taiichi Yuasa, Kyoto University, JAPAN

1 0