Re: language design after Algol 60

bartc <bc@freeuk.com>
Sat, 14 Apr 2018 20:43:17 +0100

          From comp.compilers

Related articles
[6 earlier articles]
Re: language design after Algol 60, was Add nested-function support gneuner2@comcast.net (George Neuner) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support bc@freeuk.com (bartc) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support bc@freeuk.com (bartc) (2018-04-12)
Re: language design after Algol 60 robin51@dodo.com.au (Robin Vowels) (2018-04-14)
Re: language design after Algol 60 robin51@dodo.com.au (Robin Vowels) (2018-04-14)
Re: language design after Algol 60 bc@freeuk.com (bartc) (2018-04-14)
Re: language design after Algol 60 anw@cuboid.co.uk (Andy Walker) (2018-04-15)
Re: language design after Algol 60 robin51@dodo.com.au (Robin Vowels) (2018-04-17)
Re: Language design after Algol 60 robin51@dodo.com.au (Robin Vowels) (2018-04-18)
Re: language design after Algol 60 genew@telus.net (Gene Wirchenko) (2018-04-18)
Re: language design after Algol 60 martin@gkc.org.uk (Martin Ward) (2018-05-01)
| List of all articles for this month |
From: bartc <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Sat, 14 Apr 2018 20:43:17 +0100
Organization: virginmedia.com
References: <49854345-f940-e82a-5c35-35078c4189d5@gkc.org.uk> 18-03-103 18-03-042 18-03-047 18-03-075 18-03-079 18-03-101 18-04-002 18-04-003 18-04-004 18-04-024 18-04-034 18-04-041 18-04-046 18-04-050 18-04-065
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="26625"; mail-complaints-to="abuse@iecc.com"
Keywords: design
Posted-Date: 14 Apr 2018 16:57:19 EDT
Content-Language: en-GB

On 14/04/2018 05:19, Robin Vowels wrote:
> From: "bartc" <bc@freeuk.com>
> Sent: Friday, April 13, 2018 4:40 AM
>
>
>> But it is not adding extra syntax; if anything it is getting rid of it!
>> If a for-loop starts like this:
>>
>>     for i:=1 to n do ...
>>
>> Then by leaving out the bits not needed you end up with this:
>>
>>     to n do ...
>
> The control variable, i, must not be omitted.
> It may be required for computations within the loop
> (including subscript references).
>
> Even if not explicitly referenced within the loop,
> its value will be required for fault finding (with error control
> and/or with debugger).


Huh? Who says that?


This example is from my language (inspired by Algol68), where the
control variable /can/ be omitted. And it's not needed any more than you
need one here for this line of code repeated three times:


          print "*"
          print "*"
          print "*"


(For that matter, it can be omitted from a C for-loop too, if only
because that language is so crude it doesn't even have the concept of a
control variable for a loop.)


>> A repeat-n-times loop (one that doesn't have to maintain an explicit
>> loop counter accessible as a reference-counted variable from the source
>> code).
>
> It's still required, as described above.


If implemented as an actual loop (rather than unrolling or whatever),
then there might be a count kept somewhere. But it doesn't need to be in
a format compatible with the regular variables in the language or be
part of its type system.


The count might also increment upwards or downwards; more likely the latter.


If a loop index is needed for fault-finding, then you just switch over
to for-loop that does have the index.


--
bartc


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.