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

[iterate-devel] Proposed patch to ITERATE::FREE-VARS
by Robert Goldman 05 Jan '12

05 Jan '12

Steve Haflich from Franz kindly clarified to me my misunderstanding of special-operators and macros. In particular, he pointed out to me that implementations are free to implement special operators as macros. Steve writes: "I assure you that the set of special operators in ACL is _fixed+, and that there is way for you, the _user_, to extend that set. But this requirement of the ANS does not require that the set of cl-package symbols that return true under spcial-operator-p is not larger than the required operators in the table you quoted from http://www.franz.com/support/documentation/current/ansicl/subsubsu/specialf… Now see here: http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor… specifically An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided." He goes on to explain how this works in ACL: "In ACL user(31): (macro-function 'return) #<Function macroexpand-1-transform> so cl:return names _both_ a special operator and a macro. In our opinion, this is explicitly recognized by the ANS. (I think I remember being there when we of X3J13 voted this issue, but I also think I think I sometimes remember things that never occurred. Your mileage may vary.) Unfortunately, this seemingly innocent divergence from the standard breaks the code walker in ITERATE (and may break other code walkers, as well). I haven't examined this particular code walker, but I speculate that it is checking special-operator-p _before_ checking macro-function. A _portable_ walker should give the latter priority, which is what Franz believes the "implementation is free" codicil intends." Steve's understanding of the code walker in FREE-VARS is correct. Actually, over and above this, there seems to be a second bug in the code-walker: the check of (MACRO-FUNCTION (CAR FORM)) is not inside the branch for (SYMBOLP (CAR FORM)). So I believe that fixing this bug is not just a matter of pandering to ACL users, but actually a matter of fixing an incorrect code walker that could cause problems for arbitrary lisp implementations. I have attempted to fix this bug by moving the branch for MACRO-FUNCTION into the branch for SYMBOLP (CAR FORM) and moving it up before the check for SPECIAL-OPERATOR-P. See attached patch. I'd be obliged if you could review it for incorporation. It reduces the number of test failures in Allegro CL to the same as the number for SBCL: one. Best, R

1 0

[iterate-devel] Differences between lisps
by Robert Goldman 05 Jan '12

05 Jan '12

I find that ACL 8.2 gets 4 failed tests on the latest iterate from darcs: 4 out of 261 total tests failed: ITERATE.TEST::CODE-MOVEMENT.ELSE, ITERATE.TEST::CODE-MOVEMENT.FINALLY, ITERATE.TEST::CODE-MOVEMENT.FINALLY-PROTECTED, ITERATE.TEST::BUG/WALK.2. where SBCL seems to get only 1. I say "seems to," since the call to ASDF:TEST-SYSTEM does not print gracefully in SBCL, probably because of the compiler being chatty: 1 out of 261 total tests failed: ITERATE.TEST::BUG/WALK.2. For CODE-MOVEMENT.ELSE, I see a problem on ACL -- the function local-binding-check does not raise an error on ACL, although it *IS* invoked. The bug seems to further be localized to the fact that the following returns NIL on ACL: (free-variables form) looking further, this suggests that something goes wrong in the code-walker in FREE-VARS. Looking further, I think I have identified the divergence --- in ACL, CL:RETURN is a special-operator, and in SBCL, it is not: Allegro: CL-USER> (special-operator-p 'return) #<special operator RETURN @ #x1000054c32> SBCL: CL-USER> (special-operator-p 'return) NIL I believe the appropriate fix is to include RETURN in the first list of special symbols in the case statement. This will be benign for SBCL (it won't visit that, since RETURN is not a special-operator), but should fix things for ACL. Making that change, I see that now both ACL and SBCL have only one test failure. Best, r

1 1

[iterate-devel] Darcs problems...
by Robert Goldman 05 Jan '12

05 Jan '12

It seems that the problems were due to a version mismatch. Darcs 2.2 on my Mac OS X box was unable to fetch the darcs repo for iterate. Darcs 2.5 was. Oddly Darcs 2.2 on Linux was able to fetch it.... Cheers, r

1 0

[iterate-devel] Noob question about the darcs repo
by Robert Goldman 03 Jan '12

03 Jan '12

Although I have a common-lisp.net account, I find that I cannot clone the darcs repository: darcs get rgoldman@common-lisp.net:/project/iterate/darcs/iterate Invalid repository: rgoldman@common-lisp.net:/project/iterate/darcs/iterate darcs failed: (scp) failed to fetch: rgoldman@common-lisp.net:/project/iterate/darcs/iterate/_darcs/inventory Any idea what I'm doing wrong? Is there some anonymous way to clone this repository for people who don't have cl.net accounts? best, r

1 1

[iterate-devel] test failure: BUG/WALK.2
by Anton Vodonosov 28 Dec '11

28 Dec '11

Hello. I am running iterate tests (between other often-used CL libraries) on different Lisps. The results of continuous testing may be found here: http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html. Currently Iterate has the same failure on all the lisps: Test ITERATE.TEST::BUG/WALK.2 failed Form: (ITERATE:ITER (RETURN (IF (ODDP 1) (PROGN) 'ITERATE.TEST::EVEN))) Expected value: NIL Actual value: ITERATE.TEST::EVEN. Best regards, - Anton

1 0

[iterate-devel] Iterate symbol case changes for non-standard lower case CL implementations.
by Douglas Crosher 02 Nov '11

02 Nov '11

Hi, The Scieneer CL and ACL have non-standard versions or modes in which the standard symbols are lower case and this can be accommodated with some minor changes. Regards Douglas Crosher

1 0

[iterate-devel] Warning with sbcl atomic-decf
by Philipp Marek 27 Apr '11

27 Apr '11

Using something like (for old-val = (atomic-decf ...)) in SBCL gives a warning that (sb-ext:truly-the ...) isn't known. So perhaps there should be a #+sbcl (sb-ext:truly-the . walk-cddr) just below the "the" handling case. I've reported that as https://bugs.launchpad.net/sbcl/+bug/771673, too. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)

1 0

[iterate-devel] date iterator extension to iterate
by Venkatesan S 26 Jan '11

26 Jan '11

Hi, Olof-joachim, iterate-devel: Thanks for the help. I have written a small driver for iterate which iterates over dates in a given range. The basic usage is: (iter (for (y m d) from-date '(2011 1 26) to '(2011 2 27) by 2 skipweekends nil) (format t "~a/~a/~a~%" d m y)) notes: 1) default value for "to" is today 2) default value for "by" is 1 3) skipweekends if true, skips over weekends I would like to include this in date-calc package, as I feel it logically belongs there. Please let me know how to go about this. I am just learning lisp, and all comments/flames are welcome. In the iterate driver, I would like to reuse the given variables (y m d) instead of gensym'ming , but I get a slew of errors, which I am unable to comprehend. Instead of: (defmacro-driver (FOR (y m d) FROM-DATE from-date-spec &optional TO to-date-spec BY (n 1) SKIP-WEEKENDS (skipval t)) "Driver for iterating over dates. All dates are in YMD format, ie (YYYY MM DD)" (let ((ty (gensym "TO-YEAR")) (tm (gensym "TO-MONTH")) (td (gensym "TO-DATE")) (fy (gensym "FROM-YEAR")) (fm (gensym "FROM-MONTH")) (fd (gensym "FROM-DATE")) ..... (,kwd ,y next (progn .... (list ,fy ,fm ,fd) .... I would like to use the input yy instead of gensym'ming to hold the current iteration value like: (defmacro-driver (FOR (y m d) FROM-DATE from-date-spec &optional TO to-date-spec BY (n 1) SKIP-WEEKENDS (skipval t)) "Driver for iterating over dates. All dates are in YMD format, ie (YYYY MM DD)" (let ((ty (gensym "TO-YEAR")) (tm (gensym "TO-MONTH")) (td (gensym "TO-DATE")) ..... (,kwd ,y next (progn .... (list ,y ,m ,d) Also, any pointers to improve the code are very much appreciated. Thanks, Venkatesan -- Audentis fortuna juvat -- Audentis fortuna juvat

2 2

[iterate-devel] defclause-driver with &sequence
by Venkatesan S 23 Jan '11

23 Jan '11

Hi, I was trying to roll an iterate driver for iterating over dates and I am stuck with a problem. When using defmacro-driver, I am unable to get the value passed in from to and other sequence classes. I tried with the example given in the manual (chapter "Rolling your own"), but hit the same problem. The manual says: "We can now refer to parameters from, to, by, etc. which contain either the values for the corresponding keyword, or nil if the keyword was not supplied. Implementing the right code for these keywords is cumbersome but not difficult; it is left as an exercise." But I guess I am one of the dumb few who failed the exercise :)) The following is my attempt with the example given in the manual: (defmacro-driver (FOR var IN-WHOLE-VECTOR v &sequence) "All the elements of a vector (disregards fill-pointer)" (let ((vect (gensym)) (end (gensym)) (index (gensym)) (myfrm (gensym "myfrm")) (kwd (if generate 'generate 'for))) `(progn (with ,vect = ,v) (with ,myfrm = ,from) (with ,end = (array-dimension ,vect 0)) (with ,index = -1) (,kwd ,var next (progn (incf ,index) (if (>= ,index ,end) (terminate)) (format t "myfrm: ~a~%" ,myfrm) (aref ,vect ,index)))))) I tried using the driver with: (a is an array of 10 elements) (iter (for v in-whole-vector a from 5 below 8) (print v)) I get the following error: The variable FROM is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ((DEFMACRO CLAUSE-FOR-IN-WHOLE-VECTOR-18) (CLAUSE-FOR-IN-WHOLE-VECTOR-18 :FOR V :IN-WHOLE-VECTOR A :FROM ...) #<unused argument>) 1: (MACROEXPAND-1 (CLAUSE-FOR-IN-WHOLE-VECTOR-18 :FOR V :IN-WHOLE-VECTOR A :FROM ...) #<NULL-LEXENV>) 2: (ITERATE::PROCESS-CLAUSE (FOR V IN-WHOLE-VECTOR A FROM 5 ...)) 3: (ITERATE::WALK (FOR V IN-WHOLE-VECTOR A FROM 5 ...)) 4: (ITERATE::WALK-LIST-NCONCING ((FOR V IN-WHOLE-VECTOR A FROM 5 ...) (PRINT V)) #<FUNCTION ITERATE::WALK> #<FUNCTION (LAMBDA #) {100407D489}>) 5: (ITERATE::WALK-LIST ((FOR V IN-WHOLE-VECTOR A FROM 5 ...) (PRINT V))) 6: ((DEFMACRO ITER) ..) I am using ubuntu maverick, 10.10, SBCL 1.0.45 64 bit. I tried the following: (with ,myfrm = from) I get an error: The variable FROM is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ((LAMBDA ())) 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV ..) 2: (SWANK::EVAL-REGION "(iter (for v in-whole-vector a from 5 below 8)\n (print v))\n") 3: ((LAMBDA ())) 2) (with ,myfrm = :from) This does not throw any error, but just prints myfrm: FROM instead of the value given I want to use defclause-driver with the sequence keywords, I could not figure out how to get the values passed in from, to and other such clauses. Can anyone please provide some pointers? -- Audentis fortuna juvat

2 3

[iterate-devel] Seconded: ITER package nickname all caps - breaks readtable-case invert
by Jonathan Johansen 28 Aug '10

28 Aug '10

I think fixing this would be awesome - I like the invert case readtable setting. On Mon, Aug 23, 2010 at 10:08 AM, Vladimir Sedach <vsedach(a)gmail.com> wrote: > Hi, > > Is there a reason why the package nickname ITER is written in all > capital letters in the package definition file? cl-closure-template > uses the ITER nickname but in lowercase, and this breaks when I have > my readtable-case set to invert. Is this a bug in iterate or > cl-closure-template? I've done a search of other packages in my > site-lisp (102 of them), and none of the other ones seem to use the > nickname ITER in upper case. > > Thanks, > Vladimir > > _______________________________________________ > iterate-devel site list > iterate-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/iterate-devel >

1 0