Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!topaz!gaynor
From: gaynor@topaz.UUCP
Newsgroups: net.lang
Subject: Re: compound statements
Message-ID: <5323@topaz.RUTGERS.EDU>
Date: Sat, 12-Jul-86 06:29:36 EDT
Article-I.D.: topaz.5323
Posted: Sat Jul 12 06:29:36 1986
Date-Received: Sat, 12-Jul-86 10:28:47 EDT
References: <5281@topaz.RUTGERS.EDU> <8900039@uiucdcsb>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 69

[eat me (non-line-eaters need not apply)]

In article <8900039@uiucdcsb>, wsmith@uiucdcsb.CS.UIUC.EDU writes:
> You have your fancy, one statement function/procedure.   it's three
> screenfuls and you just found out that the fancy 1 statement function
> now is a two statement function.  Blech!  Now you have to find the
> beginning of the procedure, the end of the procedure and add a begin/end
> pair at the ends.

In my original posting, I outlined several cases when one could argue
that the delimeters were necessary (and I quote):

    (1) If the code [example code included, ~2/3 of a page, one single
        deeply nested 'if-then-else'] were any longer, one could argue
        that it's done to increase readability by imposing delimeters.

    (2) If the code were any longer, one could argue that it's done as
        a built-in error check.

I certainly did not mean to imply that these arguments are invalid!
Sorry for any misconceptions there.  They certainly are valid, under
the conditions you outlined.  But those conditions are NOT the same as
those under which I based my argument.  I specifically referred to the
shorter pieces of code that are written.  Besides the references
above, I remind the reader of the conditions of my argument with:

    But, the recent trends in programming place emphasis on modular
    code; hence, people are writing more, smaller procedures.

It's those smaller procedures that have no need of delimeters.  For
a really extreme example, consider:

procedure init-tree (ref tree t1) | procedure init-tree (ref tree t1)
                                  |
  t1 <- null-tree                 |   begin
                                  |       t1 <- null-tree
                                  |      end

I mean, it doesn't make a damn bit of difference whether the begin-end
pair is there or not.  Both are perfectly clear, and neither will be
any source of syntactic error in the long run...


I'm generating a "Somebody-Else's-Problem Field" for your next issue.

Errors in both block delimitation and statement seperation/termination
may cause both local AND global errors in most languages.  Generally,
though, the sep/term errors are much more localized than the block
delimeter errors.

> [ discussion concerning inadvertant leftover seps/terms in    ]
> [ if ... then ... ; ...  --> if ... then ... ; else ... ; ... ]

> [ discussion asserting local changes should affect local ]
> [ code only and how the above errors are non-local       ]

> Bill Smith

                         _   /|
                         \`o_O'
                           ( )   Aachk! Phft!   
                            U

Disclaimer: The opinions and/or information and/or code expressed
            here were generated by this characature, stolen from
            Dave Rasmussen, to which I have taken the liberty of
            adding ears.  So don't look to me for a disclaimer!

Silver  {...!topaz!gaynor}