Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsm!wsmith
From: wsmith@uiucdcsm.cs.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: Block Closure
Message-ID: <5200003@uiucdcsm>
Date: 19 Apr 88 13:45:00 GMT
References: <18@<Apr>
Lines: 41
Nf-ID: #R:<Apr:18:uiucdcsm:5200003:000:2156
Nf-From: uiucdcsm.cs.uiuc.edu!wsmith    Apr 19 07:45:00 1988


firth@sei.cmu.edu (Robert Firth) writes:
> It seems clearly desirable that every control construct be able to
> contain multiple statements, embedded within clear starting and
> ending delimiters.

I obviously missed something in this discussion.  What is wrong with single 
character delimiters for a compound statement such as { and } as C uses?  
They do not clutter up the program and distract the reader of the program 
from seeing the also important data flow of the program.

With a reasonable text editor based language oriented editor, the editor
can reliably format the indentation of the program automatically and  help 
a programmer visualize the control structure without imposing awkward
command languages in the editor.  The editor could also show the 
programmer where the matching } to any { is.  The language oriented editor 
could also do this with case-esac or case-end case, but clutter should be 
considered when designing a language.

The problem with the idea mentioned in other postings about using indentation
to represent the control structure is that it does not have a clean formalism
to describe the parser.  Many languages that are in use can be described with
LR derived parsing specifications and thus the syntax of the language can
be dealt with formally.   I don't think that using whitespace as part of the 
syntax of the language will be easy to parse.   Problems include: handling
of multi line expressions and defining default tab stops.

It is important that a language be described in a formalism that can
be understood and reasoned about.  The lexical specifications may be
described with regular expressions (regardless of how the expressions
are implemented).  Context free grammars can be used to specify the
syntax.  If the language has constructs that are impossible to fit
an a context free framework, parsing becomes more difficult, prototyping
the language becomes more difficult and implementing the language correctly
becomes more difficult.  

I think the jury is still out on the best way to specify formally semantic 
information about a program.

Bill Smith
ihnp4!uiucdcs!wsmith
wsmith@a.cs.uiuc.edu