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

noitalmost <noitalmost@cox.net>
Thu, 13 Jan 2011 13:09:24 -0500

          From comp.compilers

Related articles
[37 earlier articles]
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-12)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-12)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-12)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-13)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-13)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-13)
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)
[12 later articles]
| List of all articles for this month |

From: noitalmost <noitalmost@cox.net>
Newsgroups: comp.compilers
Date: Thu, 13 Jan 2011 13:09:24 -0500
Organization: Compilers Central
References: 10-12-040 11-01-005 11-01-025
Keywords: design

On Thursday, January 06, 2011 03:45:23 pm George Neuner wrote:
> 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?
>
> You're absolutely right that a language doesn't need 10 ways to
> accomplish the same thing ... I fully agree that having too many
> equivalent choices is needless waste. But apparently redundant
> features can be justified by programmer convenience as well as for
> unique uses.


My language solution addresses this sort of compromise. I'm providing
traditional While, infinite Loop, and Break statements. If you have a Break,
you only need one loop construct to provide pre-, post-, and mid-test loops.
The While is provided simply for programmer convenience.


while x < y :
x := getAnother();
end;


loop :
if x >= y :
break
end;
x := getAnother()
end;


I'm trying to work out whether I can uniformly provide a
keyword : body end
construct and then provide shorthands in which eliminating the colon also
indicates a single-statement body with no end
if x >= y break;
I'm trying to make it so the compiler can give good error messages for common
errors (missing/extra colon, missing/extra end, etc).


As another convenience, I'm also considering an Unless statement (kind of like
in Perl).
unless x < y : break



Post a followup to this message

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