gmane.lisp.iterate.devel

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.

iterate tests regression on SBCL 1.0.54 (quicklisp2012-04-07 vs 2012-03-07): handler-bind.1

Anton Vodonosov — 2012-05-06T22:39:32

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-RAJv0FSm0WjXUTgYha9U7tUSAzwo4V3HxonJSNx5TPSEwRcW2ca7clAc5pJIh5JZjhMS7GZWQih7hViiC7OmZfY1onNIBciD7m6kbVJu9FeiRgeGEtwrPd4YxXx-dB-y6UPs8LFQN5_-st7G9ICpZVRLkA
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.

Bug: "collect at beginning" ignores specifiedsequence type

Ilya Perminov — 2012-03-27T22:49:33

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< at >common-lisp.net/msg00142.html

Thanks,
Ilya

ELS 2012, Zadar, Croatia

Marco Antoniotti — 2012-02-01T13:13:50

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

ELS2012 Zadar, Croatia, Call for Papers

Marco Antoniotti — 2012-01-23T11:59:23

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




_______________________________________________
iterate-devel site list
iterate-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/iterate-devel

Proposed patch to ITERATE::FREE-VARS

Robert Goldman — 2012-01-05T21:10:49

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

Now see here:
http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor.htm
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
--- /Users/rpg/lisp/iterate/iterate.lisp2012-01-05 13:38:20.000000000 -0600
+++ /Users/rpg/lisp/vendor/iterate/iterate.lisp2012-01-04 19:34:52.000000000 -0600
< at >< at > -2078,8 +2078,6 < at >< at > (defun free-vars (form bound-vars)
      nil)
     ((symbolp (car form))
      (cond
-       ((macro-function (car form) *env*)
-        (free-vars (macroexpand-1 form *env*) bound-vars))
        ((or (special-operator-p (car form))
             ;; Lucid doesn't think that these are special forms
             ;; and we need to handle declarations:
< at >< at > -2121,6 +2119,8 < at >< at > (defun free-vars (form bound-vars)
                 (nconc free-vars (free-vars-list body bound-vars))))
           (otherwise
            nil)))
+     ((macro-function (car form) *env*)
+      (free-vars (macroexpand-1 form *env*) bound-vars))
        (t ; function call
         (free-vars-list (cdr form) bound-vars))))
     ((and (consp (car form)) (eq (caar form) 'lambda))

Re: Differences between lisps

Robert Goldman — 2012-01-05T02:30:19

...snip...


Oh, dear.  Looking further into the hyperspec, I see that this seems to
be a case where ACL collides with the ANSI spec....

I will report this to Franz as a bug.

Best,
r

Differences between lisps

Robert Goldman — 2012-01-05T02:22:11

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 < at > #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

Darcs problems...

Robert Goldman — 2012-01-05T01:40:21

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

Proposed patch to ITERATE::FREE-VARS

Robert Goldman — 2012-01-05T21:10:49

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

Now see here:
http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor.htm
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
--- /Users/rpg/lisp/iterate/iterate.lisp2012-01-05 13:38:20.000000000 -0600
+++ /Users/rpg/lisp/vendor/iterate/iterate.lisp2012-01-04 19:34:52.000000000 -0600
< at >< at > -2078,8 +2078,6 < at >< at > (defun free-vars (form bound-vars)
      nil)
     ((symbolp (car form))
      (cond
-       ((macro-function (car form) *env*)
-        (free-vars (macroexpand-1 form *env*) bound-vars))
        ((or (special-operator-p (car form))
             ;; Lucid doesn't think that these are special forms
             ;; and we need to handle declarations:
< at >< at > -2121,6 +2119,8 < at >< at > (defun free-vars (form bound-vars)
                 (nconc free-vars (free-vars-list body bound-vars))))
           (otherwise
            nil)))
+     ((macro-function (car form) *env*)
+      (free-vars (macroexpand-1 form *env*) bound-vars))
        (t ; function call
         (free-vars-list (cdr form) bound-vars))))
     ((and (consp (car form)) (eq (caar form) 'lambda))

Re: Differences between lisps

Robert Goldman — 2012-01-05T02:30:19

...snip...


Oh, dear.  Looking further into the hyperspec, I see that this seems to
be a case where ACL collides with the ANSI spec....

I will report this to Franz as a bug.

Best,
r

Differences between lisps

Robert Goldman — 2012-01-05T02:22:11

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 < at > #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