Hoehle, Joerg-Cyril writes:
> Pascal Bourguignon wrote:
> "The error is in clisp implementation of loop where a default result is
> computed at the beginning of the loop, instead of waiting the
> terminating conditions to determine default values."
>
> Although I can't find anything in the CLHS supporting Pascal
> Bourguignon's opinion and evaluation model (last
> always/thereis/until evaluated yields default), at least it has the
> advantage that
> + it assigns meaning to a form which otherwise has none (never+thereis)
> + it is deterministic (all proposed models share this property :-)
> However
> - defaults are constantly changed within the loop, possibly leading
> to surprising results
>
> (loop repeat 3 while nil always t)
> -> nil with Pascal, since always is never reached. ; bad!
> -> t in current CLISP (always clause => t default) ; good!
Only in the case of an ambiguity between always, never and thereis
should the default of the last executed clause be used. This is the
interpretation of the other implementations, even those who issue a
_warning_ in this case.
while or until don't impose any default result.
always, never and thereis do.
There are two differences between the thereis and until constructs:
* The until construct does not return a value or nil based on the
value of the supplied form.
* The until construct executes any finally clause. Since thereis
uses the return-from special operator to terminate iteration, any
finally clause that is supplied is not evaluated when exit occurs
due to thereis.
...
The constructs always, never, and thereis provide specific values
to be returned when a loop terminates.
(loop repeat 3 while nil always t) should still return t, like in ecl,
gcl, sbcl, cmucl.
The other examples, where there is only one of always, never and
thereis and no other return value, should still return the default for
the one clause.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.

J=C3=B6rg-Cyril H=C3=B6hle wrote:
> at least it has the advantage that it assigns meaning to a form
> which otherwise has none (never+thereis)
I don't think this is an advantage. Especially in the LOOP area, other
implementations are known to assign meanings to ambiguous forms. When a
user runs in clisp a program with was developed with another implementation,
it is better to give an error (or at least a warning) for ambiguous forms,
rather than returning a different result than the other implementation and
letting the user wonder why his program misbehaves.
Bruno

Hi,
I'm sorry. I just realized that CLHS explicitly disallows never+collect.
It says in ?6.1.4 "Using always, never, or thereis in a loop with value accumulation clauses that are not into causes an error of type program-error to be signaled (at macro expansion time)."
Therefore, Sam's patch must be rejected.
Instead, my never+collect example should even be turned into a failure test (i.e. the testsuite should contain a case to check that (typep (nth-value (eval'(loop never+thereis))) 'program-error)).
Now,
1. given that there cannot be a value from an accumulation overiding a default from thereis/always/never, and
2. given that always/never is quite limited because it cannot appear outside the main clause (e.g. when (plusp x) always (integerp x) is not covered by the BNF),
I'm left to wonder what the CLHS wants to say when it talks about the clause "supplies a default value of t/nil": when does this apply?
Since value accumulation clauses are disallowed, what can "some other clause [which] contributes a return value" be in CLHS?
Sam Steingold wrote:
>there is a thread on c.l.l on this:
>http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/t
hread/df090483c0b8b58e/ba3d05cc52eef601?tvc=1&q=group:comp.lang.lisp+loop+thereis&_done=%2Fgroups%3Fq%3Dgroup:comp.lang.lisp+loop+thereis+%26qt_s%3DSearch+Groups%26&_doneTitle=Back+to+Search&scrollSave=&&d#ba3d05cc52eef601
Pascal Bourguignon wrote:
"The error is in clisp implementation of loop where a default result is
computed at the beginning of the loop, instead of waiting the
terminating conditions to determine default values."
Although I can't find anything in the CLHS supporting Pascal Bourguignon's opinion
and evaluation model (last always/thereis/until evaluated yields default), at least it has the advantage that
+ it assigns meaning to a form which otherwise has none (never+thereis)
+ it is deterministic (all proposed models share this property :-)
However
- defaults are constantly changed within the loop, possibly leading to surprising results
(loop repeat 3 while nil always t)
-> nil with Pascal, since always is never reached.
-> t in current CLISP (always clause => t default)
(loop for i in '()
always (plusp i)
do (foo i))
would yield nil, which, from a mathematical point of view, is quite odd IMHO.
(and I see a relationship to (AND) => t, not nil)
A possibly not too contrived example which would benefit from lifting a contradiction between always/never and thereis might be as follows:
(loop for x in '(-3 2 0 2.5)
always (numberp x)
when (plusp x) collect x into y
thereis (foo x)
finally (return y))
which can return either nil, (foo x) or a list of positive numbers...
Regards,
Jorg Hohle.

Mail addressed to
"john@..."
was ambiguous, but was delivered to
John_G_Dorsey (john)
The name "john" also matched the following users
Full name (login name)
Andrew_John (aj14)
Bonnie_John (bej)
To avoid this warning message in the future, address the mail as
"John_G_Dorsey@..."