Re: language design implications for variant records in a pascal-like language

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Fri, 14 Jan 2011 09:43:11 +0100

          From comp.compilers

Related articles
[43 earlier articles]
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2011-01-13)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-14)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-14)
Re: language design implications for variant records in a pascal-like cfc@shell01.TheWorld.com (Chris F Clark) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-15)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-16)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-16)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-17)
Re: language design implications for variant records in a pascal-like torbenm@diku.dk (2011-01-17)
[6 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Fri, 14 Jan 2011 09:43:11 +0100
Organization: Compilers Central
References: 10-12-040 10-12-043 11-01-005 11-01-025
Keywords: syntax, design
Posted-Date: 15 Jan 2011 00:22:38 EST

George Neuner schrieb:


> Why do so many languages offer (at least) two forms of conditional
> loop: one with the test at the beginning and another with the test at
> the end? Why not just offer an infinite loop and a way to break out
> that can be tied to any conditional?


With a look at grammars themselves, I found EBNF much easier to read and
write than BNF, except for (some) repetitions. The >=0 repetition {...}
    does not allow to express >0 repetition, so that one has to write
      list ::= some lengthy construct { "," some lengthty construct }.
That's why constructs like
      list ::= ( some lengthy construct )/",".
have been added to e.g. Borland EBNF.


[The typo in the first list left in intentionally...]


Obviously the required loop constructs vary with the domain of a
language. That's why IMO general purpose languages should allow for
several loop constructs, which should be easy to distinguish by
humans.


DoDi



Post a followup to this message

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