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

Re: [iterate-devel] Fwd: if-first-iteration, a little better vers ion as an arch patch
by Hoehle, Joerg-Cyril 10 Jan '06

10 Jan '06

Attila Lendvai wrote: >And finally a new version of if-first-iteration: That's more or less that, minor a few points (a documentation string, bind step-body after first-usage to avoid setf, usage of make-accum-var-binding, and probably eliminate the no-else code generation test (let the compiler do that)). I'll add it to the next version (not immediately, I'm too busy right now). I hope this is ok. BTW, what's the iteration pattern that lead you to define this and not use IF-FIRST-TIME? Could you show some sample/imaginary code? Thanks for your contribution. Regards, Jörg Höhle

2 1

[iterate-devel] Fwd: if-first-iteration, a little better version as an arch patch
by Hoehle, Joerg-Cyril 10 Jan '06

10 Jan '06

Attila Lendvai wrote: [writing Iterate extensions using iterate::* instead of exported symbols. >And after looking at the code it wasn't >obvious (for me, newbie warning). Maybe I should add a comment here and there (in code and/or TeX documentation). The implementation somewhat obviously(?) uses the internal interfaces. So of course this leads to copy&paste of this code. Actually, it's a critique of mine towards Iterate that I haven't yet identified a subset of primitives with which to write the many other Iterate clauses, and so that they work as efficiently as the predefined ones. It's missing this "growing a language" concept. >issuing a tla redo. Just in case... Indeed, I'm not yet using arch/tla. For now it doesn't make much sense since I cannot (yet?) access common-lisp.net as a developer. Thanks for the info. I just recently jumped into darcs (cffi), but did not yet try out Arch or subversion. Regards, Jörg Höhle.

2 1

[iterate-devel] wanted: complex uses of iterate, for inclusion in the testsuite
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Hi, I'd like to extent the testsuite with tests of Iterate involving several clauses. Because of things like feature interaction, I'm convinced that some bugs in software cannot be found out by testing each clause separately, as the current testsuite tends to exercise. Instead, one clause may affect the other (I know a few cases), and such complex multi-clause usage is presumably more representative of uses of Iterate by you, the application developers, than the present rather primitive testsuite. Therefore, I'd like to ask you for multi-clause uses of Iterate for inclusion in the testsuite. It could then also serve as source of nice examples to other users. Thanks, Jörg Höhle.

1 0

[iterate-devel] Fwd: if-first-iteration, a little better version as an arch patch
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Attila Lendvai wrote: >and a tla undo patch this time. Ah, I was wondering what the many strange files meant :-) I wonder why people submitting patches tend to write code against Iterate's internal structures, instead of writing using the external interface? After all, being able to expand Iterate via regular macros was one of John Amsterdam's design goals. What about something along (defmacro-clause if-first-iteration (then &optional else) `(progn (with ,(gensym) = t) (if ,gensym ,then ,else) (after-each (setq ,gensym nil))) If you really want to hack the internals, I suggest not introducing another special variable, but instead add to the existing binding variables. You can still generate a single variable for all uses of IF-FIRST-ITERATION in one Iterate by using a technique similar to that of iter::return-extremum-code. That would integrate better IMHO into the existing code base. Regards, Jörg Höhle.

2 1

Re: [iterate-devel] Accessing the result in finally clauses
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Attila Lendvai wrote: >Namely baing able to reference the loop result in finally >clauses as "it". Please try out iterate::*result-var* and report results. Couldn't you use named variables? >Any toughts? You should try to stay away from the anaphoric variable IT in LOOP. It's confusing (working in this clause, not working in that other one). Regards, Jörg Höhle.

2 1

[iterate-devel] Accessing the result in finally clauses
by Attila Lendvai 07 Jan '06

07 Jan '06

Hello, I'm missing a feature that i even tried to implement without any luck for now. Namely baing able to reference the loop result in finally clauses as "it". (iter .... (finally (return `(progn ,@it))) Any toughts? - attila

1 0

[iterate-devel] Fwd: if-first-iteration, a little better version as an arch patch
by Attila Lendvai 07 Jan '06

07 Jan '06

hello again, sorry for the flood, this i a little better version of if-first-iteration that creates only one variable. and a tla undo patch this time. happy coding, - attila ps: the attachment is very small, but if it's not welcome to send patches to the list please tell me where to send them.

1 0

[iterate-devel] ASDF installability of the package
by Ignas Mikalajunas 07 Jan '06

07 Jan '06

Hi, i wanted to download the most current iterate, but i am geting 403 error. Should I just use 1.4.0 or is that a bug ? Ignas Mikalajūnas

3 2

[iterate-devel] if-first-iteration
by Attila Lendvai 07 Jan '06

07 Jan '06

hi! thanks for iterate, it's coool! :) i'm new to lisp, and while hacking i was missing if-first-iteration which is enclosed in the mail. sorry for a simple paste, but learning arch seems to be a bigger task then writing the actual feature. it was fun looking at a complex macro lib. bear with me if the code is naive, i'm way too new to lisp for patches like this. i think the clause name tells it all, feel free to include. happy coding, - attila lendvai (def-special-clause IF-FIRST-ITERATION (then &optional else) (setf then (list (walk-expr then))) (setf else (list (walk-expr else))) (let ((var (make-var-and-binding 'first-iteration t :type 'boolean))) (return-code :body (list (if else `(cond (,var ,@then) (t ,@else)) `(when ,var ,@then))) :step (list `(setf ,var nil)))))

1 0

Re: [iterate-devel] Iterate download error
by Hoehle, Joerg-Cyril 05 Jan '06

05 Jan '06

François-René ÐVB Rideau wrote: >For portability reasons, maintainability, future proofness, I think >you really need use such a MY-DELETE function, even on implementation >that *currently* provide the "obvious" implementation of DELETE. Ok, will do. I should stick to what I propagate most of the time :-) Better feel safe than sorry. Regards, Jörg

1 0