From: <Joe...@t-...> - 2017-12-22 10:52:54
|
Hi, Sam Steingold wrote: > (and the committee did not reach a consensus because implementing this behavior is relatively hard Uh? Implementations are mentioned (old Genera, MIT LOOP) and they did no particular magic. Here we have some fundamental disagreement. I claim that LOOP should not be hard because no used expects it to expand into some too clever magic that would require special operators not yet invented that, besides, would prevent code walking projects out there from processing clisp's LOOP -- not a good idea. If it mustn't be hard, we just need to find the good compromises, i.e. (re)ordering vs. dependability Meeting user expectations will be especially hard when discussing FINALLY. I've seen wishes either side - from (loop for x on list finally (return x) ; some want nil, others the last restlist - from (loop for x below N finally (return x) ; some want N-1 (undefined if N<=0), others N! But that's left for a future 2018 "About values in the LOOP epilogue". I'll be off email for the next 3 weeks. >> (loop for a = (princ 1) then b for b below (princ 2) do (princ (list a b))) >> would print 21 by that proposal. >This behavior does not stand the WTF test. [...] >if VARS is bound to non-NIL, this does not stand the WTF test. Please explain WTF. Is this test case not relevant? Don't you want to assign semantics to this form? To me there's a difference between portable (CL) semantics and implementation-defined semantics. E.g. within FINALLY, a variable's value may not be portably defined, yet we can document "In clisp's loop the named driver variable will have value ... in FINALLY". >Let us start with code samples and what they should return, not with "how we should macroexpand LOOP". You are right, I have code samples in mind constantly, but nowhere in the text. >> - Disallows LOOP-FINISH within INITIALLY, as the (GO epilogue) tag is not visible. >No, people expect this. You're right. LOOP-FINISH needs to work within INITIALLY (trivial if it's within the one TAGBODY). >I must admit that I did not study your proposals in detail yet, Sure. It's long and not particularly elaborate. I had sketched an even longer text, found it too academic and rewrote parts into that "proposal" form. >but it would be nice if you could augment it with actual code: That's what I wanted to avoid. I don't want to implement LOOP a dozen times, then vote on "the best". I wanted to discuss the semantics, then implement them. > (let ((x '(a b c d))) (loop repeat 2 for x in x collect x)) >==> (a b) Sure. Where is the problem? I see no problem at all. That's the semantic I want to give it. Regards, Jörg |