#

## Issue LOOP-MISCELLANEOUS-REPAIRS Writeup

    Issue:        LOOP-MISCELLANEOUS-REPAIRS
    Document:     (no document number yet)
    Forum:        Cleanup
    References:   refer to the referenced Public Review comments
    Category:     CLARIFICATION
    Edit history: 14-Feb-93, Version 1 by Moon
                  18-Feb-93, Version 2 by Moon (fix spelling error)
    Status:       Proposal FIX passed 7-1-0, March 1993

    Problem Description:

      There were public review comments relating to chapter 6 of draft 12.24.
      This cleanup does not address the complete set, just the easier ones
      since it makes sense to lump them all into one omnibus issue.  I have
      not included editorial comments in this cleanup.

      A brief summary of the comments:

      1. Flanagan #4, Loosemore #3, Moon #47 -- extension mechanism is
      promised but not included

      2. Moon #28 -- text says "Function Designator", examples work differently

      3. Moon #30 -- LOOP "IT" Description doesn't make sense

      4. Moon #32 -- LOOP DOING doesn't allow implicit progn, but DO does

      5. Moon #35 -- LOOP-FINISH Inconsistency

      6. Moon #37 -- Does LOOP RETURN clause return multiple values?

      7. Moon #41 -- LOOP Conditional Execution Nonsense

      8. Moon #43 -- LOOP Bad Type-Spec Example

      9. Moon #21 -- LOOP Block Name Scope is not specified

      10. Moon #34 -- LOOP Thereis Default is not specified

      11. Moon #24 -- LOOP-AND-DISCREPANCY:NO-REITERATION not incorporated

      12. Moon #25 -- LOOP by/to phrase Order should be unrestricted

      13. Moon #36 -- LOOP Return/Named Interaction

      14. Moon #26 -- Eliminate the ability to put a LOOP keyword after FINALLY

    Proposal (LOOP-MISCELLANEOUS-REPAIRS:FIX)

      Make all of the following numbered changes:

      1. Remove reference to extension mechanism on page 6-32.

      2. Change definition of step-fun on page 6-5 to:

        \param{step-fun}---a \term{form} that evaluates to a \term{function}
        of one \term{argument}.

      3. Replace the entire paragraph beginning "clause, clause1" on page 6-5
         with:

          \param{Clause}, \param{clause1}, \param{clause2} --
          \i{unconditional} | \i{accumulation} | \i{conditional}, as defined
          in the section "Syntax of an Extended LOOP Form".

         Replace the last paragraph on page 6-18 with:

          The \term{loop keyword} \loopref{it} can be used to refer to the result
          of the test expression in a clause.
          Use the \term{loop keyword} \loopref{it} in place of the form in a
          {\tt return} clause or an \i{accumulation} clause that is
          inside a conditional execution clause.
          If multiple clauses are connected with \loopref{and}, the \loopref{it}
          construct must be in the first clause in the block.

        In a Notes section, note that:

          Use caution when using a variable named {\tt it} (in any package) in
          connection with LOOP, since \loopref{it} is a \term{loop keyword} that
          can be used in place of a form in certain contexts.

      4. Add DOING to the next-to-last paragraph on page 6-5.

      5. Remove the following paragraph from p.6-7:

          Note also that the \macref{loop-finish} macro terminates iteration and
          returns any accumulated result. Any \loopref{finally} clauses that are
          supplied are evaluated.

      6. Change the next-to-last paragraph on p.6-7, the third paragraph on
         p.6-19, and the last paragraph on p.6-19 all to state clearly that all
         values returned by the form in a RETURN clause are returned by the LOOP.

      7. Replace the first three paragraphs under the heading Conditional
         Execution on p.6-18 with:

           The \loopref{if}, \loopref{when}, and \loopref{unless} constructs
           establish conditional control in a \macref{loop}. If the test
           passes, the succeeding loop clause is executed. If the test does
           not pass, the succeeding clause is skipped, and program control
           moves to the clause that follows the \term{loop keyword}
           \loopref{else}. If the test does not pass and no \loopref{else}
           clause is supplied, control is transferred to the clause or
           construct following the entire conditional clause.

           If conditional clauses are nested, each \loopref{else} is paired
           with the closest preceding conditional clause that has no
           associated \loopref{else} or \loopref{end}.

           In the \loopref{if} and \loopref{when} clauses, which are
           synonymous, the test passes if the value of \param{form} is
           \term{true}.

           The \loopref{unless} \param{form} construct is equivalent to
           \f{when (not \param{form})}; the test passes if the value of
           \param{form} is \term{false}.

      8. Add OF-TYPE to the example on page 6-24.

      9. State explicitly in the next to last paragraph on page 6-19 that the
         scope of the block name includes the entire LOOP. Move the "BLOCK NIL"
         in the example on page 6-17 so it is outside the LET*.

      10. Add the following sentence to the description of "thereis" in the
          section "Termination Condition Clauses" on p.6-7:

           Otherwise, it provides a default return value of \nil.

      11. Make the syntax and the English agree with the X3J13 vote on
          LOOP-AND-DISCREPANCY:NO-REITERATION (Version 1) by correcting
          the syntax for each for-as subclause on page 6-3 by removing
          the "\curly{\loopref{for} | \loopref{as}}"; by adding the
          same text to the front of the definition of for-as-clause on
          page 6-3; and by adding a sentence to the second paragraph on
          page 6-9 clarifying that the word FOR or AS is not repeated
          after the word AND.

      12. The detailed description of for-as-arithmetic (p6-9) should say
          in English that the "by" subclause can appear either before or after
          the "to" subclause, and similarly for the other two pairs of
          subclauses. The syntax of for-as-arithmetic on p.6-3 should be
          changed as follows, to allow the three subclauses to appear in any
          order, to require at least one subclause to be used, and to indicate
          the restrictions on combinations of prepositions described in
          English on pp.6-9..6-10:

          for-as-arithmetic ::= { FOR | AS } var [ type-spec ]
           { { FROM | UPFROM } form1 [ { TO | UPTO | BELOW } form2 ] [ BY form3 ]
    |
             { FROM | UPFROM } form1 BY form3 [ { TO | UPTO | BELOW } form2 ] |
             { TO | UPTO | BELOW } form2 [ { FROM | UPFROM } form1 ] [ BY form3 ]
    |
             { TO | UPTO | BELOW } form2 BY form3 [ { FROM | UPFROM } form1 ] |
             BY form3 [ { FROM | UPFROM } form1 ] [ { TO | UPTO | BELOW } form2 ]
    |
             BY form3 { TO | UPTO | BELOW } form2 [ { FROM | UPFROM } form1 ] |
             FROM form1 { DOWNTO | ABOVE } form2 [ BY form3 ] |
             FROM form1 BY form3 { DOWNTO | ABOVE } form2 |
             { DOWNTO | ABOVE } form2 FROM form1 [ BY form3 ] |
             { DOWNTO | ABOVE } form2 BY form3 FROM form1 |
             BY form3 { DOWNTO | ABOVE } form2 FROM form1 |
             BY form3 FROM form1 { DOWNTO | ABOVE } form2 |
             DOWNFROM form1 [ { TO | DOWNTO | ABOVE } form2 ] [ BY form3 ] |
             DOWNFROM form1 BY form3 [ { TO | DOWNTO | ABOVE } form2 ] |
             { TO | DOWNTO | ABOVE } form2 DOWNFROM form1 [ BY form3 ] |
             { TO | DOWNTO | ABOVE } form2 BY form3 DOWNFROM form1 |
             BY form3 [ { TO | DOWNTO | ABOVE } form2 ] DOWNFROM form1 |
             BY form3 DOWNFROM form1 [ { TO | DOWNTO | ABOVE } form2 ]
           }

          Yes, it looks complicated, that's the limitation of BNF to express
          things where not all permutations are allowed.

      13. Replace the second sentence of the next-to-last paragraph on page 6-7
          with:

            It is equivalent to the clause
            \f{do (return-from \i{block-name} \i{value})},
            where \i{block-name} is the name specified in a \loopref{named}
            clause, or \nil if there is no \loopref{named} clause.

          Replace the second sentence of the third paragraph on page 6-19
          with the text quoted just above.

      14. Remove the syntax "finally unconditional-clause" on page 6-4.  Remove
          the sentence "An unconditional clause can also follow
          \theloopkeyword{finally}." from the sixth paragraph on page 6-8.

    Test Cases:

      Refer to the referenced Public Review comments

    Rationale:

      These are non-controversial corrections to mistakes or ambiguities in
      the draft specification.

    Current Practice:

      All of these changes bring the specification into conformity with current
      practice as observed in Apple MCL 2.0p1, with the exception of the ability
      to put the BY subclause before both of the other subclauses in #12.  I
      believe it would be a one-line change to the implementation to allow that.

    Cost to Implementors:

      Little or none for most implementations that already conform.

    Cost to Users:

      Probably none.

    Cost of Non-Adoption:

      Ambiguous, inconsistent, or incomprehensible language specification.

    Benefits:

      Better language specification.

    Aesthetics:

      Better language specification.

    Performance Impact:

      None.

    Discussion:

      None.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.