Can someone please explain why the finally clause below doesn't execute
after normal iteration terminates:

(loop for i from 1 to 10
   collect i
   finally collect 11)

returns:
(1 11 2 11 3 11 4 11 5 11 6 11 7 11 8 11 9 11 10 11)

Which is no different than:

(loop for i from 1 to 10
   collect i
   collect 11)

Is it just not possible to collect final values in the loop epilogue?

 Adam> (loop for i from 1 to 10
 Adam>    collect i
 Adam>    finally collect 11)

 Adam> returns:
 Adam> (1 11 2 11 3 11 4 11 5 11 6 11 7 11 8 11 9 11 10 11)

 Adam> Which is no different than:

 Adam> (loop for i from 1 to 10
 Adam>    collect i
 Adam>    collect 11)

After a FINALLY you have to put a compound-form (a Lisp expression,
rather than a LOOP keyword), except that you are getting faked out
because you know that RETURN is allowed there (as a special case).

The consequences of the code FINALLY COLLECT are undefined, but your
implementation (CLISP I bet) happens to handle this by just totally
ignoring the bogus FINALLY clause.

 Adam> Is it just not possible to collect final values in the loop epilogue?

  compound form n. a non-empty list which is a form: a special form, a
                   lambda form, a macro form, or a function form.

the collect clause is not a compound form!

(loop for i from 1 to 10
      collect i into nums
      finally (return (nconc nums (list i))))

But I'm not sure if accessing i in the finally clause actually should lead
to a 10 or an 11 at the end of the list. I've tried to check it in the
HyperSpec but did not find something about that.

Actually it would be probably more safe to do

(loop for i from 1 to (1+ 10) collect i)

If you want to collect one further step.

ciao,
Jochen

  (nconc
    (loop ...)
    (list foo-last))

It turns out to be clearer and less verbose than the loop way!:

  (nconc (loop for i from 1 to 10 collect i)
    '(11))

  I see no such special case in the standard, only compound-forms.

--
Erik Naggum, Oslo, Norway

(loop for i from 1 to 10
      collect i
      finally nil
      collect 11)

But if I was implementing LOOP I would signal, at least, a warning in
this case.

 Erik>   I see no such special case in the standard, only compound-forms.

Hmm, I think you're probably right about that, but I was thinking
about the language in 6.1.7.2 talks about "Clauses such as return,..."
followed by "Such an explicit return inside the finally clause..."
which makes it sound like there is some special hack for FINALLY RETURN.

The BNF definitely agrees with you that there is no such hack, so that
ought to settle it.  But the above language is a little bit confusing.

  initial-final::= initially compound-form+ | finally compound-form+

Is this what you are looking for?

  Consider a function `range´

(defun range (from to)
  (loop for i from from to to collect i))

 You could use it like this:

(loop for x in `(a b c ,@(range 1 3) d e f) ...).

--
Erik Naggum, Oslo, Norway

Let's define the above as a function and then call it twice:

(defun dumb-loop ()
  (nconc (loop for i from 1 to 10 collect i)
    '(11)))

[2]> (dumb-loop)
(1 2 3 4 5 6 7 8 9 10 11)
[3]> (dumb-loop)
(1 2 3 4 5 6 7 8 9 10 11)

That's fine. But this time let's do some destructive modification on
the output:

[6]> (nconc (dumb-loop) '(12))
(1 2 3 4 5 6 7 8 9 10 11 12)
[7]> (nconc (dumb-loop) '(12))
(1 2 3 4 5 6 7 8 9 10 11 12 12)

Oh no! dumb-loop, which you expect to be a list of 11 numbers is
returning a different result each time.

You can no longer rely upon the quoted 11 to be 11 any more. It is
destructively modified when linking the lists together, but this only
becomes apparent when it is no longer the last term in the list
construction.

I suggest the above loop should at least have been coded this way:

   (nconc (loop for i from 1 to 10 collect i)
     (list 11))

Which agrees with Timothy Moore's recent comment in another thread: "That
quoted list is constant.  If you're going to fool around with nconc (and I
don't see what you find so distasteful about the use of append) better
try (nconc list (list 'element))."

The issue was adding a final term to a list. As I wrote earlier in
the thread:

   Thanks. I had already done this (the last item isn't supposed to be a
   constant like the example above):

     (nconc
       (loop ...)
       (list foo-last))

I provided the note on the effect of using nconc & quoted values for the
benefit of people learning Lisp. By your humorous rationale I could have
avoided the whole issue of using loop by writing:

   (reverse (maplist #'length (make-sequence 'list 11)))

  Both solutions were, I think, intended to solve the more general problem,
  but I now see that your major gripe is not the loss of features of `loop´,
  but consing up a brand new list, and this is a more valid concern in my
  view.  The even more general problem than we solved would thus be a case
  such as

(loop for code from 32 to 95 then from 160 to 255
  do (... something with ISO 8-bit character set conventsions ...))

  which would certainly be more convenient than, say,

(loop for code from 32 to 255
  unless (< 95 code 160) ...)

  So I am sympathetic to your request now that I understand your goal better.

  The `loop´ macro is normally supplied in source form with your Common Lisp
  implementation, so it should be possible to modify it locally, with all the
  drawbacks that has.  I concur that some community effort to define such a
  mechanism would be useful, and it should be addable without serious
  compatibility problems because `then´ is not a valid clause.

--
Erik Naggum, Oslo, Norway

(loop for x in '(1 2 3) then from 1 to 10 then on '(1 2 3) ...)

I don't think that there is a standard way of doing this other than
simply doing something to create an object with is the `concatenation'
of all these things.  Some versions of LOOP have a way of defining new
clauses, so one could probably use that to define something like this
(I'm not sure if you could use `for' though?).

--
Janos Blazi

(Digression: I learned just this weekend that Scott Fahlman, one of the
CLtL1 Gang of Five, and a productive member of X3J13, Chair of the
"Cleanup Committee", is believed to be the inventor of the ":-)"
emoticon.  See http://news.com.com/2100-1023-957817.html?tag=fd_top )

When X3J13 adopted the LOOP macro, it was a devisive and contested
decision.  There was a subcommittee on iteration that did the study
of iteration system proposals.  I vaguely remember the vote was only
something like 60/40.  Most X3J13 decisions of such grand importance
were more-decisively for or against.

The argument against the non-simple LOOP was that it had irregular,
un-lispy syntax, was hard to read in complex cases, and therefore
didn't always do what the programmer expected.  The argument in favor
was mostly that LOOP was well understood in practice, there was a lot
of existing code that used it, and that it was something that a
significant portion of practicing near-CL programmers would expect to
use in their code.  The latter argument carried (and I was one voting
in favor).  I personally use lloop, and like the kinds of things it
expresses concisely and eloquently.  I also recursively macroexpand
any nontrivial loop I write before compiling to make sure it really
does what I think it does.  So you can see that I agree with both
sides in the original dispute; but I think it is good to have
non-simple LOOP in the language, just like it is good to have format
strings.  (Nearly every argument against LOOP can be applied verbatim
against format strings.)

But there were two other proposed iteration systems that contended
with the historical LOOP macro:  One was Richard Waters' (or Pretty
Printer fame) "Series" package, and the other was "Generators and
Gatherers" by Waters and  Crispin Purdue, which (IIRC) was a later
proposal based on experience with Series.  Both were more Lispy
and functional than the macro swamp of LOOP.

Neither of these was adopted, although the committee generally felt
that both were technically, conceptually, linguistically, and
morally superior to LOOP.  The difficulty (IIRC) was that there was
less experience using these systems, and perhaps they needed more
exercise and trials with efficient implementation before being
committed to the standard.  The committee (IIRC) generally hoped that
these would be kept available in portable packages, and perhaps
optimized by implementors, so that they could be used and perhaps
later become a regular part of the langauge.  They are not part of
the ANSI standard, but there are good writeups of these two packages
in CLtL2, appendixes A and B respectively.

I know that the series package is readily available on the web.
Check http://series.sourceforge.net/ and other standard places.