Are the bugs listed on the site still exist and have they been fixed yet. I'm at work now, so I can't look at the package more until I get home. Are there any bugs listed in the iterate package that are not on the website.
Hoping a can fix a few.
Are the bugs listed on the site still exist and have they been fixed yet.
o The nested hash-table is long gone. Who wants to fix the html page?
o I don't consider the "previous and initially" issue a bug. "I suspect it's a doc bug", as Andreas Fuchs wrote. Maybe it's not logical from a math. point of view, or maybe the math. model need be changed.
o The wishlist about macrolet (and flet and all shadowing issues) is still current. It's a basic limitation of the implementation, and I believe it's a basic limitation of the design (or possibly of ANSI-CL API): macroexpander and code-walkers get in trouble with lexical environments. A truly non-trivial issue.
o Not mentioned, and recently reported by Kilian Sprotte: (for (a b) ='(1 2)) (for pa previous a) (for pb previous b) (print (list pa pb a b))
Another issue would be to enhance compatibility with LOOP even more: LOOP FOR FROM DOWNTO etc. does not always translate 1:1 to Iterate keywords. Maybe that's a place for a small patch? Or maybe nobody but me ever noticed or cares?
Hoping a can fix a few.
Great!
BTW, there's that empty CVS directory in the iterate project directory. Shall I delete it or does it serve some purpose?
Regards, Jörg Höhle
o The wishlist about macrolet (and flet and all shadowing issues) is still current. It's a basic limitation of the implementation, and I believe it's a basic limitation of the design (or possibly of ANSI-CL API): macroexpander and code-walkers get in trouble with lexical environments. A truly non-trivial issue.
fyi, there's a quite good walker in arnesi hiding platform dependency. the #L reader in arnesi is using it and macrolet works with it. unfortunately it should be factored out into a separate lib, just like the call/cc transformer using it. it's on my TODO, but long at the end.
BTW, there's that empty CVS directory in the iterate project directory. Shall I delete it or does it serve some purpose?
i don't have it in my repo. try 'darcs w -l', it should say that it's a new file by prefixing it with a small 'a' letter. then you are free to delete it from the repo's point of view.
Hi,
Attila Lendvai wrote:
fyi, there's a quite good walker in arnesi hiding platform dependency. the #L reader in arnesi is using it and macrolet works with it. unfortunately it should be factored out into a separate lib, just like the call/cc transformer using it. it's on my TODO, but long at the end.
Just for the record, any portable code walker is *not* a solution. IIRC, last time I looked, arnesi cannot handle UNWIND-PROTECT or EVAL-WHEN -- for obvious reasons. Iterate has a code walker that is as good as a portable code walker can go (portable in the ANSI CL glossary meaning). What's needed is some non-portable integration with the various implementations, so that the environment is handled correctly (*macroexpand-hook* is not enough). Such functionality could be factored out indeed, in a separate library. Maybe also PCL's code-walker has implementation-specific code?
BTW, there's that empty CVS directory in the iterate project
directory. Shall I delete it or does it serve some purpose? i don't have it in my repo.
Oh, it's not in Darcs, it's in ~iterate/, not in the Darcs/ subdir.
BTW, unsatisfied with the limitations inherent in Iterate's current implementation, I've been looking at various list comprehension designs (Mario Latendresse, Sven-Olof Nyström, Olin Shivers, SRFI-42). Iterate is still interesting and it's unclear to me whether the actual problem is either: - Iterate's design, which requires a code-walker to detect gatherers nested deep within the body - ANSI CL limitations, which make macros that depend on a code-walker a can of worms, making designs like Iterate hard if not unsuitable.
Note that LOOP, SRFI-42 and all the others do not depend on a code walker. They all supply their own grammar and thus know where clauses can appear (at top-level of the form).
BTW2, send me an e-mail if you want an enhanced version of Mario Latendresse's comprehension macro. (When I'll have more time, I'll post to cliki).
Regards, Jörg Höhle
Just for the record, any portable code walker is *not* a solution. IIRC, last time I looked, arnesi cannot handle UNWIND-PROTECT or EVAL-WHEN -- for obvious reasons. Iterate has a code walker that is as good as a portable code walker can go (portable in the ANSI CL glossary meaning).
please note that arnesi has two things: a generic code walker (with support for platform independent access to platform specific environments) and using this it has a CPS transformer for delimited continuations (the with-call/cc stuff).
the latter naturally has the usual questions connected to call/cc but the former should be trivially extended to support everything needed. but yes, it's not a usable solution out of the box.
btw, these functionalities should be factored out into separate libs, TODO entry 1243141... :)
but my knowledge is not crystal clear about these things, so take it with a grain of salt...