Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!gaynor
From: gaynor@topaz.RUTGERS.EDU (Silver)
Newsgroups: net.lang
Subject: Re: compound statements
Message-ID: <5358@topaz.RUTGERS.EDU>
Date: Fri, 18-Jul-86 11:27:51 EDT
Article-I.D.: topaz.5358
Posted: Fri Jul 18 11:27:51 1986
Date-Received: Sat, 19-Jul-86 03:33:34 EDT
References: <5281@topaz.RUTGERS.EDU> <8900039@uiucdcsb> <1986Jul18.023314.21855@utcs.uucp>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 79

In article <1986Jul18.023314.21855@utcs.uucp>,
flaps@utcs.uucp (Alan J Rosenthal) writes:

> In article <8900039@uiucdcsb> wsmith@uiucdcsb.CS.UIUC.EDU writes:
> >
> >Another argument for forcing the brackets on a function:
> >
> >You have your fancy, one statement function/procedure.   it's three
                 ^^^^^
      spelt c-o-m-p-l-i-c-a-t-e-d

> >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.

I think it's relatively clear that my original gripe was that
sometimes a certain elegance is lost on a small procedure when
enclosed within a compound statement.  Perhaps the sheer unnecessity
of a delimeter is distracting if it is present.  I would NEVER
recommend this practice with a procedure of any great length or
complexity - in fact, I came out and said it time and time again that
the example included (about 2/3 of a screenful) was borderline.  I
chose the example carefully (not the algorithm itself - it was on my
mind, and happened to be the right length and complexity).  Any
smaller or less complex, disclude.  Any larger or more complex,
include.  Just that size and complexity, total up the debits and the
credits, and then decide.

Do your homework BEFORE you post.  Saves on phone bills.

[ I apologize to those who are annoyed by seeing every little thing ]
[ spelt out repeatedly.  I find it annoying to do.                  ]

> [...]
> 
> Braces on a one-statement function should be optional for the same reason
> that programs can compile without being able to pass lint.  I use lint
> myself, but if you don't, you might as well still be able to use the
> compiler.

Lint's general purpose is to detect bad programming practices.  If I
were lint, I would only complain about the abscence of the compound
statement in question only if the code was greater than 20 or so
lines and/or unusually complex (ie containing deeeeep nesting, gotos
(which probably would flag lint anyway, don't bother correcting me if
I'm wrong), things of that ilk).

  Warning: procedure wsmiths_fancy_one_statement_procedure long enough
           to warrant enclosure in compound statement (length: 68)

  Warning: procedure deeply_nested_if complicated enough to warrant
           enclosure in compound statement (nesting: 6)

> Now if functions without braces are harder to parse, that's a different
> question.

Consider the major parsing schemes.  It makes little difference to a
parser generator.  I did it in a *simple* recursive-descent parser in
minutes.  Without going into a heavy discussion, it depends more upon
the individual language and ambiguity.  Error recovery will probably
be a bit tougher, but not impossible.  It all depends upon the
language.

> Alan J Rosenthal
> {cbosgd|ihnp4}!seismo!mnetor!utcs!flaps, utzoo!utcs!flaps


                         _   /|
                         \`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
            modifying.  So don't look to me for a disclaimer!

Silver  {...!topaz!gaynor}