Changeset 37927 in project


Ignore:
Timestamp:
09/29/19 18:29:52 (3 weeks ago)
Author:
sjamaan
Message:

foof-loop: Formatting

File:
1 edited

Legend:

Unmodified
Added
Removed
  • wiki/eggref/5/foof-loop

    r37926 r37927  
    607607several classes:
    608608
    609   - /Loop variables/ are initialized at the beginning of the loop and
    610     updated at every iteration by rebinding (not by assignment).  Loop
    611     variables are bound in the user termination conditions, the user
    612     variable expressions, the loop body, and the final expression.
    613 
    614   - /Entry variables/ are bound when each iteration of the loop is
    615     entered, before the termination conditions have been tested.  They
    616     cannot be updated like loop variables; each is always initialized
    617     on loop entry to the value of the same expression.  This means that
    618     the expression need not be duplicated at the beginning of the loop
    619     and when the loop is continued.  Entry variables arise only from
    620     iterators, and are bound in the user termination conditions, the
    621     user variable expressions, the loop body, and the final expression.
    622 
    623   - /Body variables/ are bound at each iteration of the loop only if no
    624     iterator has terminated the loop.  Body variables arise only from
    625     iterators, and are bound in the user termination conditions, the
    626     user variable expressions, and the loop body.
    627 
    628   - /User variables/ are bound after body variables have been bound,
    629     but before WHILE and UNTIL conditions for terminating the loop.
    630     User variables are introduced by LET and LET-VALUES clauses in
    631     LOOP.  User variables are bound only in the user termination
    632     conditions and the loop body.
    633 
    634   - /Final variables/ are bound once at the end of the loop.  Final
    635     variables arise only from iterators, and are bound only in the
    636     final expression.
     609* ''Loop variables'' are initialized at the beginning of the loop and updated at every iteration by rebinding (not by assignment).  Loop variables are bound in the user termination conditions, the user variable expressions, the loop body, and the final expression.
     610* ''Entry variables'' are bound when each iteration of the loop is entered, before the termination conditions have been tested.  They cannot be updated like loop variables; each is always initialized on loop entry to the value of the same expression.  This means that the expression need not be duplicated at the beginning of the loop and when the loop is continued.  Entry variables arise only from iterators, and are bound in the user termination conditions, the user variable expressions, the loop body, and the final expression.
     611* ''Body variables'' are bound at each iteration of the loop only if no iterator has terminated the loop.  Body variables arise only from iterators, and are bound in the user termination conditions, the user variable expressions, and the loop body.
     612* ''User variables'' are bound after body variables have been bound, but before WHILE and UNTIL conditions for terminating the loop. User variables are introduced by LET and LET-VALUES clauses in LOOP.  User variables are bound only in the user termination conditions and the loop body.
     613* ''Final variables'' are bound once at the end of the loop.  Final variables arise only from iterators, and are bound only in the final expression.
    637614
    638615The loop is controlled by the loop clauses:
     
    11991176to this, and two reasons motivating it:
    12001177
    1201   (C1) After updating <number> as a loop variable to some number N,
    1202        <number> as a body variable in the next iteration will be
    1203        <step> *less* than N.
    1204 
    1205   (C2) <Number> will be initialized to the value of <high>, but
    1206        unless the loop terminates with zero iterations, neither the
    1207        loop variable <number> nor the body variable <number> will
    1208        ever be observed with the value <high>.  In the rare case that
    1209        the loop terminates with zero iterations, <number> may be
    1210        observed in the final expression with the value of <high>.
    1211 
    1212   (R1) As repeated in the introduction, lower bounds are inclusive,
    1213        and upper bounds are exclusive.  However, <high> - <low> may
    1214        not be an integral multiple of <step>, so that <number> may
    1215        never be <low>.  With the semantics chosen, <number> will at
    1216        least always be in the interval [<low>, <high>], and in fact
    1217        as a body variable always in the interval [<low>, <high>);
    1218        only in the rare case of a loop terminated after zero
    1219        iterations will <number> be observable with the value <high>.
    1220        (Of course, with explicit updates, it may take on any value.)
    1221 
    1222   (R2) When there is no lower bound, it is often useful (a) to write
    1223        user-supplied termination conditions in terms of <number>, and
    1224        (b) to use, in the final expression, the value of <number>
    1225        that induced termination of the loop.  The example of a vector
    1226        quick-sorting routine below illustrates such a use of <number>
    1227        in scanning backward from the end of a subvector past elements
    1228        greater than the pivot.
     1178(C1) After updating <number> as a loop variable to some number N,
     1179<number> as a body variable in the next iteration will be
     1180<step> *less* than N.
     1181
     1182(C2) <Number> will be initialized to the value of <high>, but
     1183unless the loop terminates with zero iterations, neither the
     1184loop variable <number> nor the body variable <number> will
     1185ever be observed with the value <high>.  In the rare case that
     1186the loop terminates with zero iterations, <number> may be
     1187observed in the final expression with the value of <high>.
     1188
     1189(R1) As repeated in the introduction, lower bounds are inclusive,
     1190and upper bounds are exclusive.  However, <high> - <low> may
     1191not be an integral multiple of <step>, so that <number> may
     1192never be <low>.  With the semantics chosen, <number> will at
     1193least always be in the interval [<low>, <high>], and in fact
     1194as a body variable always in the interval [<low>, <high>);
     1195only in the rare case of a loop terminated after zero
     1196iterations will <number> be observable with the value <high>.
     1197(Of course, with explicit updates, it may take on any value.)
     1198
     1199(R2) When there is no lower bound, it is often useful (a) to write
     1200user-supplied termination conditions in terms of <number>, and
     1201(b) to use, in the final expression, the value of <number>
     1202that induced termination of the loop.  The example of a vector
     1203quick-sorting routine below illustrates such a use of <number>
     1204in scanning backward from the end of a subvector past elements
     1205greater than the pivot.
    12291206
    12301207The more persevering reader, no doubt now exhausted by the above
     
    12941271Accumulators generally have the following forms:
    12951272
    1296 - Unconditional:
     1273* Unconditional:
    12971274
    12981275    (FOR <result> (<accumulating> <datum>))
    12991276
    1300   <Datum> is evaluated and its value accumulated.
    1301 
    1302 - Conditional:
     1277<Datum> is evaluated and its value accumulated.
     1278
     1279* Conditional:
    13031280
    13041281    (FOR <result> (<accumulating> <datum> (IF <condition>)))
    13051282
    1306   <Condition> is evaluated; if it yields true, <datum> is evaluated and
    1307   accumulated.
    1308 
    1309 - COND-style -- if <condition> is true, apply the value of <mapper> to
    1310   the value of <condition> to yield the value to accumulate:
     1283<Condition> is evaluated; if it yields true, <datum> is evaluated and
     1284accumulated.
     1285
     1286* COND-style -- if <condition> is true, apply the value of <mapper> to the value of <condition> to yield the value to accumulate:
    13111287
    13121288    (FOR <result> (<accumulating> <condition> => <mapper>))
    13131289
    1314   <Condition> is evaluated; if it yields true, <mapper> is evaluated
    1315   and its value applied to the value of <condition>.  What <mapper>
    1316   returns is accumulated.
    1317 
    1318 - Extended (SRFI 61) COND-style:
     1290<Condition> is evaluated; if it yields true, <mapper> is evaluated
     1291and its value applied to the value of <condition>.  What <mapper>
     1292returns is accumulated.
     1293
     1294* Extended (SRFI 61) COND-style:
    13191295
    13201296    (FOR <result> (<accumulating> <generator> <tester> => <mapper>))
    13211297
    1322   <Generator> and <tester> are evaluated, and the value of <tester>
    1323   applied to arguments of the values yielded by <generator>.  If
    1324   <tester> returns true, <mapper> is evaluated and its value applied
    1325   also to arguments of the values yielded by <generator>.  What
    1326   <mapper> returns is accumulated.
     1298<Generator> and <tester> are evaluated, and the value of <tester>
     1299applied to arguments of the values yielded by <generator>.  If
     1300<tester> returns true, <mapper> is evaluated and its value applied
     1301also to arguments of the values yielded by <generator>.  What
     1302<mapper> returns is accumulated.
    13271303
    13281304Subexpressions such as <datum>, <condition>, &c., are evaluated in an
Note: See TracChangeset for help on using the changeset viewer.