Re: Programming language and IDE design

"BartC" <bc@freeuk.com>
Wed, 23 Oct 2013 19:09:42 +0100

          From comp.compilers

Related articles
[2 earlier articles]
Re: Programming language and IDE design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2013-10-20)
Re: Programming language and IDE design genew@telus.net (Gene Wirchenko) (2013-10-20)
Re: Programming language and IDE design genew@telus.net (Gene Wirchenko) (2013-10-21)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-10-22)
Re: Programming language and IDE design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2013-10-23)
Re: Programming language and IDE design wclodius@earthlink.net (2013-10-22)
Re: Programming language and IDE design bc@freeuk.com (BartC) (2013-10-23)
Re: Programming language and IDE design monnier@iro.umontreal.ca (Stefan Monnier) (2013-10-24)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-10-24)
Re: Programming language and IDE design martin@gkc.org.uk (Martin Ward) (2013-11-07)
Re: Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-08)
Re: Programming language and IDE design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2013-11-08)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-08)
[14 later articles]
| List of all articles for this month |

From: "BartC" <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Wed, 23 Oct 2013 19:09:42 +0100
Organization: virginmedia.com
References: 13-10-016 13-10-022
Keywords: design
Posted-Date: 23 Oct 2013 21:07:21 EDT

"George Neuner" <gneuner2@comcast.net> wrote in message
> On Thu, 17 Oct 2013 11:06:26 +0100, Martin Ward <martin@gkc.org.uk>
> wrote:


>>This also affects programming language design:
>>
>>(1) Rather than use "{" and "}" for every type of grouping, each
>>different type of group such as an if statement or while loop, should
>>have its own opening and closing keywords. This is something that
>>modern COBOL gets right (along with the many things it gets wrong!)
>
> C's mistake was not in using (or over using or abusing) curly braces.
> Rather, C's mistake was in defining the scope of its control
> constructs to be a single statement rather than a demarcated list of
> statements. Had C control constructs always expected a list of
> statements - thus *requiring* the scoping braces - many stupid
> programmer errors might have been avoided.


C source code is quite resilient (when it comes to adding/removing
newlines, copy&pasting etc). But I have a problem with braces, because
there are so many combinations of ways to place them (especially, as
you say, when they are also optional), and they tend to get in the way
too.


> I don't object to closing keywords [in fact I prefer Pascal-like
> syntax, though Modula3 and Oberon are better examples than Pascal
> itself] but I don't agree that they necessarily make errors easier to
> spot for human readers. Closing keywords are nothing more than
> syntactic punctuation, and punctuation in human language normally is
> absorbed by readers at a subconscious level.
>
> I despise stupid keyword reversal closings such as IF..FI - loop can
> go jump in the pool and tceles sounds to me like a high speed train
> (and probably is a homophone for a swear word in some language).
>
> Things like <keyword>..END<keyword> get unwieldy when keyword phrases
> may contain optional attributes, such as in generalized loop
> constructs where the demarcation keywords may have to include labels
> and/or conditions.
>
> My preference is simply for a common END keyword used by all
> constructs. I think keyword case consistency is important, but I think
> the choice to use all upper or all lower should be left to the
> programmer.


My own syntax uses 'end' for all block endings. But it also allows an
optional keyword to follow, such as 'end if', in which case it must
match the one that opens the statement containing the block.


There are also (built-in) macros that allow forms such as 'endif' to
be used (so making the space optional), as well as the obligatory
'fi', 'esac' and 'od', which map to 'end if', 'end case' and 'end do'.
(I've used 'fi', 'esac' and 'od' for 30 years, they seem completely
natural to me. However, 'hctiws', 'pool', 'nigeb', 'noitcnuf' and such
look seriously weird...)


[ COMMENT looks fine to me TNEMMOC -John]


Anyway, I provide a choice, and the extra forms allow the compiler to
pick up mismatched 'end's too.


> Python got many things right, but the whole idea of significant
> indentation in a modern language is a non-starter. I understand why
> Guido thought it might be a good idea, but he really should have left
> it alone.


(As it happens, my current project is to translate code written in the
syntax of my choice, into Python (as well as a one or two more
mainstream languages). The indented format is trivial to generate, but
since I will rarely need to look at it, I don't care what it looks
like! I just prefer that in the source syntax, a block of statements
needs to be terminated, which at least tells you when you've reached
the end (and don't have more lines off the screen, or accidently
deleted!)


--
Bartc


Post a followup to this message

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