gmane.lisp.iterate.devel

Re: small feature request w/ patch

Attila Lendvai — 2013-01-04T00:27:05

pushed, thanks!

small feature request w/ patch

Ryan Davis — 2013-01-02T20:50:17

I'm trying to organize my workplace lisp libraries (from a cobble of
source checkouts and asdf-installed stuff), and we had a small patch to
iterate that I'd like in the mainline so we can consume iterate via
quicklisp.

It adds a new restart in #'ambiguity-check-clause to delete one of the
clauses to resolve the ambiguity. This has been very helpful when
developing and debugging new iterate drivers, and I don't think it has
any other relevant effects.

Attached is a dpatch created with `darcs send -O`, but if that doesn't
work here's the diff:

diff -rN old-iterate/iterate.lisp new-iterate/iterate.lisp
1322c1322,1323
<       (error "Iterate: Inserting clause ~a would create ~
---
1324c1325,1328
<              kw1 kw2))))
---


Thanks,

Bug with (collect :at :beginning)

2012-12-13T00:35:53

When collecting values into a list, if the first value collected uses (collect val :at :beginning),
and a subsequent value does not use the ":at :beginning" clause, then an error will occur: 
"The value nil is not of type cons".

The following reproduces this error:

(iterate
 (for i from 1 to 10)
 (if (oddp i)
     (collect i :at :beginning)
     (collect i)))

Fwd: using keywords in clauses

Denis Budyak — 2012-10-22T23:05:36

Second reply to Zach which should have been sent to an iterate-devel
mailing list too.

---------- Forwarded message ----------
From: Denis Budyak <budden73< at >gmail.com>
Date: Tue, 16 Oct 2012 22:15:18 +0400
Subject: Re: [iterate-devel] using keywords in clauses
To: Zach <zach.smith< at >colorado.edu>

Zach, list,
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.

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.

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 sp

Fwd: using keywords in clauses, reply 1

Denis Budyak — 2012-10-22T23:04:14

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< at >gmail.com>
Date: Tue, 16 Oct 2012 11:06:34 +0400
Subject: Re: [iterate-devel] using keywords in clauses
To: Zach <zach.smith< at >colorado.edu>

Hi Zach, list!
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-p

Re: using keywords in clauses

Zach — 2012-10-21T01:39:54

Thanks for the input Joerg.  That said I think that there still needs to be
a discussion here.

I think that it is important to note that Budden has sufficiently convinced
me that this will cause approximately zero symbol collisions because 99% of
all Iterate extensions are done by specializing on the keyword options of
existing clauses. In fact, in the short term, the only possibility of a
collision is if someone decides to declare a clause that explicitly
collides with one of Budden's keyword shortcuts, like a (defclause :FOR
...). This is probably not a valid concern. As I stated, the real concern I
can see is that this could be the first step down the road to limited
extensiblility in the Iterate library.

I think that this is a matter of style and consistency, and I'm not sure
that style should stop anyone from doing something that would provide a
clear benefit. The real question is, will keyword short cuts provide
over-all benefit to users or will they be detrimental.  Unfortunately, this
extension see

Re: using keywords in clauses

2012-10-17T12:55:16

Hi,

I don't know if I qualify as a maintainer, however you'll see from the
ChangeLog that I've spent a lot of effort a few years ago to make
Iterate work in an ANSI-CL environment and fix numerous bugs.
I would not appreciate new developments that kill the original design.

Zach is very right. Packages are the CL way to have Iterate deal
with extensions. That's why Iterate keys all extensions on symbols.
symbols => packages.

Iterate is not LOOP. With loop, all clause "keywords" are found flat in the
top-level list, that's why their packages don't matter (except for CL:LOOP).

Zach suggested
Not sure if that works, because of the order of tests in the parser.
It would be a fancy user-level hack.  By that I mean it's a nice text
book example, and a user may like it and use it in his/her code.
But don't release code and libraries with that because as Zach pointed
out, it would kill extensibility as several extensions would fight for
the same keyword!
That conflict does not happen with symbols of different pac

Re: using keywords in clauses

Zach — 2012-10-16T20:26:13

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,

Re: using keywords in clauses

Zach — 2012-10-16T13:08:13

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:


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...

Re: using keywords in clauses

Zach — 2012-10-14T19:09:26

Just to point out to people on the list, you can already use keyword
arguments for things you should be able to, like :from, :below, :in,

(iter (for i :below 5) (collect i)) => (1 2 3 4)

If you encode FOR and COLLECT as special tokens that Iterate's
parser/compiler just understands you break the extensibility.  For
instance, you would not be able to define your own FOR or COLLECT.
Using the example from the manual under "Roll your own":

(defpackage test (:use :cl))

(iterate:defmacro-clause (test::FOR var IN-WHOLE-VECTOR v)
  "A new definition of the for loop."
  (let ((vect (gensym))
        (index (gensym)))
    `(progn
       (with ,vect = ,v)
       (for ,index from 0 below (array-dimension ,vect 0))
       (for ,var = (aref ,vect ,index)))))

(iter (test::for i :in-whole-vector #(1 3 5)) (collect i)) => (1 3 5)

Thus completely replacing FOR or anything along these lines would be
impossible without modifying iterate itself, and even then, it would
suffer from name collisions inherent in the keyword p

using keywords in clauses

Denis Budyak — 2012-10-14T11:58:57

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).

Re: Active?

Attila Lendvai — 2012-05-11T23:57:33

no worries, i didn't read it that way, and sorry if i sounded like
suggesting that.

re commit bits, i guess for handing some out first we need people to
step up and volunteer... ;)

i support anyone who deals with the codebase responsively (doesn't
experiment with revolutionary refactorings in the official repo).

Re: Active?

Robert Goldman — 2012-05-11T23:23:24

I certainly don't mean to criticize what you are doing: I am grateful
for it.  I just think it would be nice to get some more people with the
commit bit.  I'm probably not the ideal person myself, but perhaps we
can get a volunteer or two.  I imagine as the most active person on the
project now, it would probably be up to you to authorize such a person,
so that the cl.net admins will convey the sacred privilege.

Cheers,
r

Re: Active?

Attila Lendvai — 2012-05-11T17:58:26

well, this decision is in no way my responsibility, or is iterate "my"
project in any sense. it was just dormant when i had several patches,
so i asked for the commit bit.

but with that in mind i support that more people get commit bits, and
especially so when it comes to you Robert.

Re: Active?

Robert Goldman — 2012-05-10T00:47:55

Would you consider getting someone else into the group, then?  I am not
really in a position to volunteer for much upkeep right now, but perhaps
could help scrounge someone up.

Iterate has moved in to be one of the libraries that's used in pretty
much all of our projects, so I'm motivated to help keep it shiny.

Cheers,
r

Re: Bug: "collect at beginning" ignores specified sequence type

Attila Lendvai — 2012-05-09T22:57:58

pushed, thanks!

and sorry for the delay...

Re: Active?

Attila Lendvai — 2012-05-09T22:50:29

i'm "active", and reading the list every once in a while, and i even
have all pending issues starred, but i don't have ACL.

and also, many of the iterate bugs are due to its walker
implementation, and when i darcs initialized the hu.dwim.reiterate
repo, i kinda gave up on fixing iterate itself.

(i haven't switched to reiterate myself in my projects yet, and i'm
not planning to make it 100.00% compatible drop-in replacement,
although providing a separate package with a few clause expanders
should be simple)

Re: Active?

Robert Goldman — 2012-05-07T15:25:55

This is what I see at common-lisp.net:

iterate:x:1506:afuchs,mbaringer,alendvai,jhoehle

Perhaps it would be a good thing to give some additional people the
commit bit; I am not sure if anyone other than Attila is currently
active (apologies if I am wrong about that).

Cheers,
r

Re: Active?

Vladimir Sedach — 2012-05-07T15:09:51

I think the problem is that Attila does not read iterate-devel. There
are quite a lot of patches and bug reports submitted here in the past
2 years that haven't made it into the code.

I've CC'ed Attila. I guess another question would be is there anyone
else with access to the Iterate repository right now?

Vladimir

On Mon, May 7, 2012 at 9:48 AM, Robert Goldman <rpgoldman< at >sift.info> wrote:

Active?

Robert Goldman — 2012-05-07T13:48:53

Is this mailing list (and the iterate library) still active?

I made some patches to iterate to address issues on ACL, but I don't
believe that they are moving forward to incorporation in the library.

The last email on this list that seems to show anything like forward
motion (and that's debatable), seems to be from 2010.

There is a patch from 7 months ago from attila, though.

Cheers,
r

iterate tests regression on ACL linux 64 (quicklisp2012-04-07 vs 2012-03-07): handler-bind.1

Anton Vodonosov — 2012-05-06T22:35:25

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_yqeRupJ3ii6PsLmOuUZ0zDuQzUuJQgi_7uJX43ujwQLaaqlRBwTLkipZNoOijXq1ORRPH5fXepLeh-qO0a9Y1O6u1lEOnvDxgKYWuRnS2BWJQqPnRuvsf4xJ5KPwByJXBgamPqGXmoL413eHg
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.