[iterate-devel] Sequence variables are initialized twice

[Hoehle, Joerg-Cyril]

Bruno Daniel wrote:
>the following example shows that iter initializes
>sequence variables twice, once with 0 and once with
>the start of the range minus 1.

To me this sums up to 2 questions

o Why generate (let ((#:count nil/0)) (setq #:count 5) ...)?

That maybe has to do with an answer to whether the following two expressions
mean the same thing, i.e. whether INITIALLY can still influence
clauses like FOR and REPEAT.
It probably has to do with how Iterate creates bindings. A single LET*
has some restrictions...
(iter (with i = 5) (repeat i) (count t))
(iter (with i) (initially (setq i 5)) (repeat i) (count t))
As I found no place in the documentation about whether or not the latter form
should be supported, I'm somewhat reluctant to change the behaviour.
Iterate is a 18 year old package, so there could be code which depends
on this.
Furthermore, although let + setq does not look pretty, it is possible
that advanced compilers like cmucl and sbcl, which perform some
liveness analysis, will note that the 0 value is thrown away and not
emit code for it.  So performance critical code compiled with
performance enabling compilers does not suffer from that extra
initialization.  CLISP does no such optimization.  I don't know how
others behave.

o Why generate weird code where some initial value is set to 1+ or 1-
what one would expect?
E.g. in (for e in-vector ...), #:index is initialized to -1.
"That breaks type declarations, since one would expect index to be a
positive fixnum."

I believe this is due to the generators.  Drivers are useable as generators, and these are all translated into a sort of (for... (DO-)NEXT body) expression, so that the body can be spliced into the (NEXT ...) clause of a generator case.

In other words, Iterates now deals with code that must produce the initial value upon the first call, e.g. 0 when first called.  To keep the stepper code simple, since it's often nothing more than (incf #:index) with some end-test, the variable is thus initialized with -1, or (1- expression).

Probably it was deemed inacceptable back when that was implemented to make the stepper code more complex, as in (setq index (if (first-time-p) #:initial-index (1+ index))). That for sure is less efficient than a -1 initialization.

Now, I don't know for sure whether that's the only reason for doing so.
One can then claim that if it's the only reason, Iterate could detect whether the clause is actually used as a generator, and produce different code depending on the use as generator or not.  E.g. use -1 with generators, but something like (for x initially 0 then (1+ x)) when not used as generator.


Well, I appreciate that people look closely at what Iterate does, but sometimes I wonder why more people come up with requirements that would make the code even more complex, and fewer people with ideas about how to make it simpler :-)
Still, contributions are welcome!


>Moreover, the declaration is not very tight. dotimes does better
>on SBCL:
>(macroexpand-1 '(dotimes (i 10) (print i)))
>    (DECLARE (TYPE UNSIGNED-BYTE I))
Perhaps because on SBCL, such precise declarations matter, so SBCL goes to
some length to generate them?
At the time Iterate war written, all that mattered was probably FIXNUM, at best.

As far as SBCL is concerned, I'm not even sure such declarations are needed, since one would hope that cmucl/sbcl's type inference system would derive that from the code.  Furthermore, loops with constant bounds are a very special case.  So it's debatable whether to add declarations for such special cases.  Given good type inference, sbcl/cmucl might even be able to infer best types for (repeat <formula>) expressions, and no macro-based package can generate a good type declaration for that.

In short, I think the best place for handling types is the implementation's compiler.  Sort of separation of concerns.
Unless the user knows better than the compiler.  But macro packages do never ever have the user's knowledge.

Regards,
	Jörg Höhle.