Loop fix

[svspire]

Fixes #300 (the Matt Kaufmann bug portion of that issue).

Summary: The type-spec that ANSI allows for the loop variable in a for-as-arithmetic subclause should NOT be slavishly checked against the :from, :to, or :by (and related) values because:

• If those values are constants, the CCL compiler is already capable both of inferring their types and coercing them to the stated type of the loop variable for initialization and loop-end tests.
• If the stated type-spec of the loop variable should include a range, that range never applies to the :by value, so for the loop macroexpander to typecheck said range against the :by value is an error. (This is true regardless of whether the :by value is a constant or a variable.)
• For all values :from, :to, and :by (as well as :downfrom, :upfrom, :downto, etc.), when they are variables, other mechanisms already exist for the programmer to declare their types, such as a let binding outside the loop form. To have the type-spec of the loop variable applied to them automatically would override (and sometimes even conflict with) those other mechanisms.

I am confident that the developers of the ANSI standard never intended for the type-spec of the loop variable to be blindly applied to the other values in a for-as-arithmetic subclause by the loop macroexpander. This PR fixes that problem.

[svspire]

I wondered if there was some way to to turn the indexv-type type specifier into a ctype and then determine the numeric-ctype-class of it, and write a suitable type specifier based on that. I don't know if that's even a good idea.

There is a way: (ccl::numeric-ctype-class (ccl::specifier-type '(integer 10 20))) ;==> INTEGER That was the first thing I tried and then I realized it was pointless. If the values are constants, the compiler is already smart enough to DTRT with them and I don't think there would be any speed advantage to the compiled code (although it might be possible to make the compiler a tiny bit smarter if :by is a constant fixnum. Haven't looked at the assembler output to see if it's already doing that).

If :by etc are variables, I think it's important to let the programmer declare their types elsewhere if he/she wishes to do so. (That would be where the programmer could explicitly declare a :by variable to be a fixnum, for example.)

Might be worth further investigation to see if there's any advantage to applying the numeric-ctype-class to :by iff it's not already a declared variable with a type, but now we're talking about potentially deep surgery. As you say, this is loop, and in order to just fix MK's bug I was aiming for a minimal footprint (for now).