Hi,
I've had time to think about the issue some more (and to read the CLHS on loop yet again).
Actually, there could be somewhat distinct votes
- Eliminate or not
- FOR IN dotted list: error out (like LOOP) or not
(compatible, someone's code may depend on this) -- apparently, that's the issue where opinions diverge.
Here's what I'm going to do when I'll have time: + Eliminate *list-end-test* + FOR IN uses ENDP (like Attila favours), like LOOP 6.1.2.1.2 + FOR ON uses ATOM, like LOOP 6.1.2.1.3 + add test cases + document change in behaviour.
So FOR IN will error out on dotted lists (if iteration reaches the end).
If your software depends on the old behaviour, write your own driver, or use the completely trivial transformation: old FOR var-spec IN on dotted lists == FOR (var-spec) ON dotted-list
The elimination of a global variable which affects the behaviour is TRT. I bet no library writer whose library depends on a particular setting of that variable for his/her code to work has ever written: (defmacro my-iter (&body body) ;; I depend on this setting or I'll crash or worse, misfunction! (let ((iter::*end-test-list* 'cl:endp)) (macroexpand (cons 'iter:iter body))))
(setq iter::*end-test-list* #) is the wrong thing to do in any library that itself uses Iterate. It's clear why, isn't it?
Regards, Jörg Höhle
Here's what I'm going to do when I'll have time:
- Eliminate *list-end-test*
- FOR IN uses ENDP (like Attila favours), like LOOP 6.1.2.1.2
- FOR ON uses ATOM, like LOOP 6.1.2.1.3
- add test cases
- document change in behaviour.
to break the rule that usually only those people speak up whose interests are compromised, i speak up here that these changes are fine with me... :)
Hi,
Attila wrote:
if noone's complaining for sufficiently long, then i'll eventually push the patch, too.
Yes please push it. Don't erase the old .tex files though, as I'd like them archived somehow.
Then I'll document the *list-end-test* elimination in Texinfo.
Attila, could you please fix your recent sharp-l patch? In CLISP, (load "iterate" :compiling t) errors out. Something is wrong with EVAL-WHEN, and I haven't time to look after this. Might be a CLISP bug (feature interaction between LOAD :compiling and EVAL-WHEN).
BTW, I think the function was named sharpL for good reason: the new sharp-l-reader name is hardly distinguishable from sharp-1-reader. l1L What @#$! fonts we use.
Regards, Jörg Höhle.
Yes please push it. Don't erase the old .tex files though, as I'd like them archived somehow.
done.
i would rename the 'tex' directory to something more obvious that it's obsolete. tex-obsolete? or a file _OBSOLETE_ in the tex dir? or something like that... suggestions? maybe a toplevel 'obsolete' directory?
and i would also remove the generated pdf's in the obsolete tex dir.
Attila, could you please fix your recent sharp-l patch? In CLISP, (load "iterate" :compiling t) errors out. Something is wrong with EVAL-WHEN, and I haven't time to look after this. Might be a CLISP bug (feature interaction between LOAD :compiling and EVAL-WHEN).
BTW, I think the function was named sharpL for good reason: the new sharp-l-reader name is hardly distinguishable from sharp-1-reader. l1L What @#$! fonts we use.
ok, i'll check/fix it.
Attila, could you please fix your recent sharp-l patch? In CLISP, (load "iterate" :compiling t) errors out.
done.
i don't use clisp much, but (load "iterate" :compiling t) works here, please report back if it still fails in any way.
Something is wrong with EVAL-WHEN, and I haven't time to look after this. Might be a CLISP bug (feature interaction between LOAD :compiling and EVAL-WHEN).
the strange thing is that it needed a :execute to make (load :compile t) work, no idea why.
Attila Lendvai wrote:
Something is wrong with EVAL-WHEN, and I haven't time to
look after this.
Might be a CLISP bug (feature interaction between LOAD
:compiling and EVAL-WHEN).
the strange thing is that it needed a :execute to make (load :compile t) work, no idea why.
BTW, CLHS contains exactly this example of modifying the readtable with EVAL-WHEN. Their example has all three of :load- :compile- :evaluate -- I'm unsure why, because in today's implementations, it seems like less situations should be required [*]. Maybe they wanted to play safe?
[*] Seemingly, it's only during READ-time for either loading (interpreted?) or compiling that one needs to set the read-table. There should be no need to generate code for this in the binary fasl: it's all gone then, one would think.
Regards, Jörg Höhle.
Hoehle, Joerg-Cyril wrote:
Hi,
I've had time to think about the issue some more (and to read the CLHS on loop yet again).
Actually, there could be somewhat distinct votes
- Eliminate or not
- FOR IN dotted list: error out (like LOOP) or not
(compatible, someone's code may depend on this) -- apparently, that's the issue where opinions diverge.
Here's what I'm going to do when I'll have time:
- Eliminate *list-end-test*
- FOR IN uses ENDP (like Attila favours), like LOOP 6.1.2.1.2
- FOR ON uses ATOM, like LOOP 6.1.2.1.3
- add test cases
- document change in behaviour.
I like that. Additionally, I suggest making *list-end-test* a symbol macro (that expands to something which errors when evaluated or setf'ed), so that code that relies on it being a special variable will break immediately.
Cheers,
Hi,
I've pushed my *list-end-test* patches onto the repository. This is my first online push, please watch it.
After Attila will have pushed the Texinfo documentation, I'll document the change.
Andreas Fuchs wrote:
I like that. Additionally, I suggest making *list-end-test* a symbol macro (that expands to something which errors when evaluated or setf'ed), so that code that relies on it being a special variable will break immediately.
Interesting idea, but that'll fail in precisely the case I mentioned: (let ((iter::*list-end-test* #)) ...) will shadow the global symbol macro and not complain. So I have not added define-symbol-macro. Do you still think that it's of great value in that case?
BTW, the destructuring + PREVIOUS bug reported by Kilian Sprotte is still in. I haven't managed to locate it so far.
Regards, Jörg Höhle.
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
- document change in behaviour.
Will you edit the LaTeX or the Texinfo version of the manual? :-)
Hi,
Luis Oliveira asks:
Will you edit the LaTeX or the Texinfo version of the manual? :-)
I was waiting for this one :-)
I've now looked at your work, it looks impressive. I'm very thankful that you included a link to a directory with many output formats.
I was afraid that the printable output would not look good, as I feel it's important that there continues to be a nicely printed description of Iterate, i.e. which does not look like the output of the print menu of a web browser. Quite to the contrary, the PS and PDF output look great!
Oh, I just saw that you also translated the "don't loop, iterate" paper. Great job! I suggest you change the title page to mention that both papers are contained.
So the above are excellent reasons to switch.
However, some details got lost in the translation. E.g. iterate.dvi §3.3 reads "Note that the pati ..." which looks like a typo. Looking up the original dvi/ps/pdf, it used to say "pat{subscript]i", which was clearly related to the previous "pat[subscript:]1, pat[subscript:]2" in the text. Is there a way to re-establish such items? HTML knows about subscripting, TeX of course knows, does Info handle that?
Regards, Jörg Höhle.
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
Oh, I just saw that you also translated the "don't loop, iterate" paper. Great job! I suggest you change the title page to mention that both papers are contained.
Do you mean the HTML page that links to the various formats or the actual cover page? (which is unfortunately only generated for the tex output)
However, some details got lost in the translation. E.g. iterate.dvi §3.3 reads "Note that the pati ..." which looks like a typo. Looking up the original dvi/ps/pdf, it used to say "pat{subscript]i", which was clearly related to the previous "pat[subscript:]1, pat[subscript:]2" in the text. Is there a way to re-establish such items? HTML knows about subscripting, TeX of course knows, does Info handle that?
I couldn't find anything in the texinfo manual. It's possible for the TeX output (we can use the @mathx macro defined in iterate.texinfo) but I couldn't find a way to do that for the HTML output. Perhaps "pat_i" would be slightly better than "pati". :-/
Luis Oliveira wrote:
I suggest you change the title page to mention that both papers are contained.
Do you mean the HTML page that links to the various formats or the actual cover page? (which is unfortunately only generated for the tex output)
I meant the TeX one, which displays nothing but "Iterate": less information than e.g. the MIT paper title page.
HTML knows about subscripting, TeX of course knows, does Info handle that?
I couldn't find a way to do that for the HTML output.
This is sad. Even HTML 2.0 (quite old) knows <SUB> and <SUP>.
Perhaps "pat_i" would be slightly better than "pati". :-/
Good idea, @mathx for good TeX and is clear enough for pat_1 ... pat_i for HTML/Info. ... Does that work inside @var, as in @var{@mathx{#}}??
Thanks for your help, Jörg.
Hi,
I've updated darcs and the online Texinfo manual with my *list-end-test* patches and various other changes, and added a few more test cases (there was an example in the manual which was bogus).
Luis, there were 2 typos in the "Don't loop" paper: "higher order Dunctions" and "looo". Do you have a cat? ;-) Please report if there are more such glitches I haven't spotted.
I've updated the online pdf. I've not updated the online .html in doc/ (split across many files). I've put a single 140KB html online at http://common-lisp.net/project/iterate/iterate-manual.html
But it's not linked from the project page. Also, the release/ area is not up to date (May 2006)
Regards, Jörg Höhle
On 25/05/07, Hoehle, Joerg-Cyril Joerg-Cyril.Hoehle@t-systems.com wrote:
Luis, there were 2 typos in the "Don't loop" paper: "higher order Dunctions" and "looo". Do you have a cat? ;-) Please report if there are more such glitches I haven't spotted.
Not anymore, heh. Did I mention that I translated the manual and paper all in one go? That should explain some typos, though there was a lot of copy&paste. I will certainly send typo-fixing patches if I come across any.
-
Andreas Fuchs -
Attila Lendvai -
Hoehle, Joerg-Cyril -
Luis Oliveira -
Luís Oliveira