Re: Programming language and IDE design

"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

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