Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!render
From: render@uiucdcsb.CS.UIUC.EDU
Newsgroups: net.lang
Subject: Re: compound statements
Message-ID: <8900038@uiucdcsb>
Date: Mon, 7-Jul-86 13:10:00 EDT
Article-I.D.: uiucdcsb.8900038
Posted: Mon Jul  7 13:10:00 1986
Date-Received: Thu, 10-Jul-86 01:48:28 EDT
References: <5281@topaz.RUTGERS.EDU>
Lines: 46
Nf-ID: #R:topaz.RUTGERS.EDU:5281:uiucdcsb:8900038:000:2509
Nf-From: uiucdcsb.CS.UIUC.EDU!render    Jul  7 12:10:00 1986


I like the use of compound statements for the bodies of subprograms, 
as they better separate the declarative section from the executable
section of the code.  I wouldn't find it unbelievable, though, that
the guiding reason for the convention is that it is a carryover from the 
earliest days of language design when you needed something to visually
separate one logical section of code from another.  Ada was supposedly
designed with the hope that the syntactic structure of the code would
mirror the logical structure of the program it implemented, under the 
assumption that this would make the code more understandable.

As a sidebar to this, let me mention a related issue:

A guy I knew to be designing a language, when asked about a particular
construct he was using, told me that the syntax didn't matter because it
was "ephemeral."  In response, I argued that the syntax was very important
for a few reasons.  
(1)  Syntax is the medium through which we communicate our program to the 
     system and to other users.
(2)  A syntax which more directly expresses the algorithm used in a program 
     makes it easier to read, understand and debug that program.
(3)  People who look at a particular language construct will automatically
     form some idea of its function, regardless of whether or not they are
     familiar with the language.  The designer must therefore take great 
     pains to ensure that any construct used does not differ too wildly
     with the users' preconceptions of the function of such a construct.

I could go on, but I am interested in other peoples opinions.  So, a few
questions for open discussion:

+ What factors should go into the design of a language's syntax?  
  Readability?  Parsability?  Theoretical aesthetics?  

+ Should the syntax be as brief as possible (APL, FP), or is some verbosity
  good (Pascal, Ada)?

+ How much can be expected of the average programmer when learning and trying
  to assimilate a new language for regular usage?  In other words, is it
  reasonable to design a language which uses very unfamiliar constructs and
  notation, and, if so, what should the guidelines be when deciding this?

                                     Hal Render
                                     University of Illinois at Urbana-Champaign
                                     render@b.cs.uiuc.edu  (ARPA)
                                     render@uiuc.csnet     (CSNET)
                                     {pur-ee, ihnp4}!uiucdcs!render  (USENET)