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

Gene Wirchenko <genew@ocis.net>
Mon, 17 Jan 2011 14:36:15 -0800

          From comp.compilers

Related articles
[51 earlier articles]
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)
Re: language design implications for variant records in a pascal-like dot@dotat.at (Tony Finch) (2011-01-17)
Re: language design implications for variant records in a pascal-like genew@ocis.net (Gene Wirchenko) (2011-01-17)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-18)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-19)
Re: language design implications for variant records in a pascal-like 9cn6w6402@sneakemail.com (Peter Canning) (2011-01-18)
Re: error reporting, was language design implications genew@ocis.net (Gene Wirchenko) (2011-01-19)
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-24)
| List of all articles for this month |

From: Gene Wirchenko <genew@ocis.net>
Newsgroups: comp.compilers
Date: Mon, 17 Jan 2011 14:36:15 -0800
Organization: A noiseless patient Spider
References: 10-12-040 10-12-043 11-01-005 11-01-025 11-01-038 11-01-041 11-01-049
Keywords: syntax, design
Posted-Date: 18 Jan 2011 01:03:12 EST

On Fri, 14 Jan 2011 10:50:29 +0000, Martin Rodgers
<mcr@wildcard.demon.co.uk> wrote:


>glen herrmannsfeldt wrote:
>
>> Now, why do some languages have DO ... UNTIL, where others have
>> DO ... WHILE for "test at the end" loops?


          If the test is after the loop, it makes sense. Mind you, I do
not think that putting the test at the end makes sense. I want my
loop control up-front and would rather see
                    until <cond>
                          body
and just know that the body will be executed once for sure. Going
through the body when I know the condition means that I may be able to
desk-check much faster.


>I've always prefered languages that have both. I picked on a specific
>Basic dialect because that was the example that irritated me the most.
>*My* experience of Basic was mainly with another dialect that had
>neither WHILE mor REPEAT - you had to use IF/GOTO or FOR.


          BTDT. I loved it as much as you did.


>BBC Basic was also irritating to me because, unlike the earlier Basic
>implementations that I knew on on micros, the ROM was large enough
>to support both control structures, so why pick just one?


          Microsoft BASIC 5 had WHILE but not UNTIL.


>So I can only guess why the implementers made that choice. To be fair,
>a lot of choices made in Basic implementation of that era seem bizzarre
>to me today. They seemed pretty odd to me at the time, but I learned a
>lot about the pitfalls of language design by studying them, so at least
>they had some value for me. It's a small design space, but that may have
>helped me - at some point, language design comes down to the very
>small details that will matter to programmers and implementers. I can
>recommend this technique to anyone interested in language design - study
>entire families of dialects, their evolution, their implementions, the costs
>and trade-offs made, the context(s) and general family history.


          I always look for the philosophy of a programming language.


>Looking at the subject for this thread, I might suggest starting with the
>Algol family. ;)


Sincerely,


Gene Wirchenko


Post a followup to this message

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