[iterate-devel] *list-end-test*

Hoehle, Joerg-Cyril Joerg-Cyril.Hoehle at t-systems.com
Wed Apr 4 12:44:38 UTC 2007


Hi,

please excuse my always late replies.

>Attila Lendvai wrote on the 16th of February:
>> does anyone have any objections against pushing this:
>> Set *list-end-test* to 'endp instead of 'atom, so (iter (for foo :in
>> something-non-list)) fails instead of silently exists
>ENDP sounds like a good idea. I was under the impression that
>iterate/for/in already failed with improper lists, but if it doesn't
>yet, it really should.

I object the change.
While it could be useful in the case of (FOR IN ...), it produces behaviour incompatible with LOOP in the case of FOR ON

(iter (for x on '(1 2 . 3))
must not fail -- with default settings.

It's written nowhere, I believe, but compatibility with LOOP is a design goal (at least to me). So far I was very surprised at how compatible ITERATE has always been with LOOP, while studying its behaviour and some corner cases. I even started wondering whether ITERATE may have influenced LOOP's design or whether it was strictly the opposite.

I vaguely remember applying a few minor changes to ITERATE to have it match LOOP closer in some obscure cases (e.g. FOR BELOW UPTO ...).

The user ought to expect consistent behaviour.  Transition from LOOP to ITERATE should be smooth and trivial.

Note that both old and new behaviour differ from LOOP.  While the old one did not signal an error with FOR IN on dotted lists, whereas LOOP would (in clisp, cmucl and CormanLisp), the new one would fail to iterate FOR ON, as noted above.

So a third possibility would be to be even more compatible with LOOP, remove that variable and unconditionaly use ATOM with FOR ON and ENDP with FOR IN.

One less variable is one less cause of trouble with incompatible settings among users.  Suppose library A wants Iterate'S variable this way, while the other wants it another way?

In summary, I'm in favour of eliminating this variable *and* differentiate FOR IN-ENDP vs. FOR ON-ATOM.
pro: compatible with observable LOOP behaviour
contra: incompatible change, FOR IN on dotted lists would error out (like LOOP)
Documentation would have to be changed as well!

Actually, there could be somewhat distinct votes
1. Eliminate or not
2. 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.

Regards,
	Jörg Höhle.



More information about the iterate-devel mailing list