Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2087

Re: 100 Things

Show all headers | View raw

"BartC" <bc@freeuk.com> wrote in message 
news:85e8v.227832$gV7.159905@fx21.am4...
>
>
> "James Harris" <james.harris.1@gmail.com> wrote in message
> news:ljria6$8ka$1@dont-email.me...
>> "BartC" <bc@freeuk.com> wrote in message
>> news:K278v.218753$vB1.137675@fx36.am4...
>
>>> Yes, C's for loop is quite powerful and very flexible (although so are
>>> 'if'
>>> and 'goto'!). But it is possible to have both that, and a dedicated loop
>>> for
>>> the 99% of situations (in my case) where I do need a for-loop to just
>>> count
>>> from A to B.
>>
>> That reminds me of some more benefits of C's for construct. In addition 
>> to
>> those mentioned before if you want a step of something other than 1 your
>> languages might accept a step as in
>>
>> A to B step C
>>
>> but then if C can be positive or negative the compiler won't know whether
>> you want the loop to execute or not. If you intend the loop to always
>> ascend and C to be positive but don't know for sure that it is, for
>> example, you might have to code
>>
>>  if C > 0 then for X = A to B step C
>>
>> Programmers would often omit the initial test of C and then because it
>> didn't know whether C would be positive or negative the compiler would
>> have to select different loop termination conditions dynamically - one 
>> for
>> a rising step and the other for a falling step.
>
> But how would C's for-loop help here? Surely you still have to choose
> between a <= or >= terminating condition?

C's for loop allows the programmer to explicitly select <, <=, > or >. In 
what I understand to be your preferred syntax, though, there is nowhere to 
put the <= or >= terminating condition and there's nothing there to tell the 
compiler whether X is supposed to increase from A to B or to decrease from A 
to B. When the step is a signed variable or an expression that could be 
positive or negative and when the semantics of the language state that the 
sign of the step controls the direction of iteration how can the compiler 
generate code for the loop termination test? It needs to know the direction 
so that it knows whether to code the loop test as, say, <= or >=.

Alternatively if the language design is that the direction of the loop is to 
be controlled by the relative values of A and B rather than the step the 
compiler still has the same problem. It doesn't know whether X should ascend 
or descend and, hence, it doesn't know whether to go on while X <= B or to 
go on while X >= B. Poor compiler! I think it would have no choice but to 
write code for both tests and select between them at run time. Am I wrong?

By contrast I meant that in C one could write

  for (i = A; i <= B; i += C) /* for an ascending loop */

or

  for (i = A; i >= B; i -= C) /* for a descending loop */

and the job is done. Then there is no ambiguity over whether the loop 
variable is expected to increase or decrease. The effect in C doesn't need 
to be documented or remembered. What the programmer intends can be expressed 
clearly in the source code.

Don't get me wrong. I didn't just choose this at random. When I started on a 
design for loops I looked at the kinds of loop control you prefer. I spent 
some time on it, went over some of the same ground as I've mentioned and 
wrestled with the necessary choices: what I thought the semantics should be 
and/or how I could change the syntax so that the programmer's intentions 
could be made clear. In the end I realised the transparent simplicity of C's 
for statement removed all of those issues and just allows the programmer to 
state what is wanted.

That's not to say that there's no way to improve on C's for loop. ;-)

>> Or perhaps the programmer wanted the difference between A and B to 
>> control
>> the direction of the iteration and not the step. No one can know unless
>> the syntax is changed so that something is added to the statement like a
>> stepup or stepdown keyword. The whole thing is a terrible bundle of
>> questions and uncertainties.
>
> Maybe. Although over many years of programming the number of times I've
> needed a step other then 1 or -1 has been so few, that I actually removed
> the 'step' option from my for-loops for a couple of decades. I've put it
> back now, but require the direction to be known or indicated at compile
> time, otherwise it assumes positive. A dynamic loop-counting direction is
> too unusual a requirement for it to compromise the simplicity of the
> standard for-loop construct. There any number of ways to code such a thing
> without special language support. But if you say it's easy in C, then the 
> C
> version is still there waiting to be dusted off!

Yes, acknowledged that you can have both.

>> Another issue is the terminating value. I remember in Basic having to
>> write things like
>>
>>  for i = a to b - 1
>>
>> where the - 1 or something like it had to be added to modify the
>> termination value. C's for loop allows a natural slight adjustment to the
>> termination condition by means of < vs <=. Contrast these two
>>
>>  for (i = 0; i < len; i++)
>>  for (i = 1; i <= len; i++)
>
> Yes, C is zero-based so 0..N-1 loops might be more common than 1..N.
>
> My languages tend to be 1-based, but are also any-based, so loops might be
>
> for i :=A.lwb to A.upb do ....
>
> But I can also write a for-loop as;
>
> for i in A.bounds do ....
>
> or as just:
>
> for i in A do ...
>
> (This 'in' form expects a range value, one of the new types I suggested in
> my list).
>
> Alternatively, if we are iterating over an array, it's possible to just 
> do:
>
> forall x in A do....        # x is each value of A in turn
> forall i,x in A do ....         # and here supplies the index too.
>
> These forms will work for arrays of any base include C's 0-based ones.

Am going off topic a bit but I would be interested to hear your views on 
this. Because

  for x in A

is a good concept but, at the same time, a loop might need to iterate over 
two or more arrays rather than just one I have toyed with the following

    x = nextof A

Then each time the statement is reached x gets assigned the next value of A. 
Of course, this would normally appear in a loop. It could head a loop by 
writing something like

  loop x = nextof A
    ... loop body
  end loop

It is similar to your x in A approach but also allows other loop controls to 
be added to the same loop if required, along the lines of

  loop x = nextof A, y = nextof B
    ... loop body
  end loop

Exhaustion of either A or B would terminate the loop. A or B could be 
functions that generate sequences.

I like that the above is flexible (and also compact) but I don't think it's 
quite right yet. Any thoughts on it?

> I suppose an alternative to 'to', such as 'upto' can indicate a count to 
> N-1
> instead of 1, but it hints a bit of tackiness. (I already have, in 
> addition,
> 'downto', 'in' and 'inrev'. But so far just writing -1 hasn't been a
> problem, and does away with an extra language feature to document.
>
>> Further, a loop can be controlled by all kinds of things other than a
>> stepping integer if that's what the programmer wants: input, lists,
>> pointers, even floats can make sense with the < or <= qualifiers where
>> they would be inappropriate for the A to B form.
>
> Sure. I'm not saying discard this complex loop completely and just have a
> basic iterative loop. I'm saying have the basic forms too for the simple
> cases: 'for', 'to' and 'do'. Syntax is free!

Syntax is free and I freely acknowledge that you make good syntax choices. 
But consider: if a language includes the simpler form then its designer has 
to deal with and document its semantics for the age-old issues mentioned 
above and earlier. A given programmer may choose not to use the simpler form 
at all but if he or she has to read someone else's code the programmer might 
still need to learn the complex and somewhat arbitrary rules that the 
language applies to those loops.

>> Oh, and one more thing. This is related to the problems with your
>> preference that I mentioned in the earlier post. Significant text has 
>> been
>> written about whether the index might be modified during the course of 
>> the
>> loop. And also whether the terminating value has to be constant or not.
>> There are a number of permutations: loop index yes, terminating value no,
>> neither, both etc. Different languages have chosen differently and their
>> choices need to be documented in the language definition. These are yet
>> more things for the programmer to remember. Again, C's for loop does away
>> with all of that. The C code shows exactly what the programmer has chosen
>> to be done.
>
> Not really. What happens here:
>
> for (i=0; i<strlen(s); ++i)  ?
>
> Is strlen(s) always called once; is it called once if the compiler can
> determine that s won't change; or is it called per-iteration?

As you know, in the expressed form strlen is at least nominally called once 
per iteration. An optimising compiler might improve on that if it can prove 
that strlen(s) will not change in the loop but the programmer's intention is 
clear (even if unwise).

It's easy to rewrite in a better form such as either of these

  for (i = strlen(s) - 1; i >= 0; --i)
  for (i = 0, slen = strlen(s); i < slen; ++i)

Apart from processing the string in the same order as your original the 
latter has the advantage that if the code changes the length of the string 
then both slen and i can be adjusted as the iterations progress.

Don't worry. I don't expect to convince you and I can see the appeal of the 
simpler form.

James

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

C: 100 Things "BartC" <bc@freeuk.com> - 2014-04-29 17:57 +0100
  Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 07:40 +0100
    Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 12:16 +0100
      Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 13:54 +0100
        Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 14:39 +0100
          Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 20:18 +0100
            Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 22:40 +0100
              Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-04-30 22:09 +0000
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 23:36 +0100
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:03 +1200
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:47 +0100
              Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-01 00:35 +0100
                Re: 100 Things Andy Walker <news@cuboid.co.uk> - 2014-05-01 11:03 +0100
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 20:16 +0100
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 12:44 +0100
                Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 11:11 +0100
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 13:32 +0100
                Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 16:42 +0100
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 17:54 +0100
          Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:01 +1200
      Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 21:13 -0400
        Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:26 +0100
          Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
      Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 13:42 +1200
        Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:35 +0100
          Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 21:02 +1200
            Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 10:40 +0100
              Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 22:06 +1200
          Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 11:08 +0200
            Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 11:02 +0100
              Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 13:57 +0200
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 15:12 +0100
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 17:18 +0200
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 17:04 +0100
                Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:30 +0000
                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-02 08:30 +1200
                Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 01:29 -0400
                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 02:37 -0400
                Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 15:39 -0400
                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 17:30 -0400
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-04 20:05 +1200
                Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-04 13:28 -0400
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-05 07:40 +1200
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 22:00 +0200
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 23:24 +0100
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 08:59 +0200
                Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 09:53 +0100
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 11:22 +0200
                Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:26 +0000
                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-02 02:49 +0000
  Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 22:08 -0400
  Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-25 23:53 +0100
    Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 05:38 -0400
      Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-26 13:51 +0100
        Re: C: 100 Things rick.c.hodgin@gmail.com - 2014-10-25 04:48 -0700
  Re: C: 100 Things "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-10-25 04:50 -0700

csiph-web