From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
From: Joachim Durchholz <joachim.durchholz@munich.netsurf.de>
Subject: Re: Building blocks (Was: Design By Contract)
Date: 1997/10/16
Message-ID: <3445AB56.BF10D04@munich.netsurf.de>#1/1
X-Deja-AN: 281051002
References: <34316EC3.5B62@dynamite.com.au>
 <199710011402.QAA02444@basement.replay.com> <3432788C.E35@uk.ibm.com>
 <PdRYMWAQ1cN0Iw4X@treetop.demon.co.uk>
 <mheaney-ya023680000410970119430001@news.ni.net>
 <5w3FnzA6KRR0Iwt+@treetop.demon.co.uk>
Reply-To: "joachim.durchholz@"@munich.netsurf.de
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-10-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Paul Johnson wrote:
> 
> I agree that the repeated read (or whatever instruction) before the
> loop and at the end is a bad idea.  Quite apart from the Soloway
> experiment, it is duplicating code.

Me too (on both accounts).

> OTOH I wonder if the situation might be reversed in real life
> situations with deeply nested structures.  I'm rather dubious of
> small, neat coding experiments such as Soloway's.

I can support that from personal experience. Whenever code involved
'break'ing out from several nesting levels deep, it was rather
unreadable and difficult to decipher.

However, there's a middle ground between "break only at top of loop" and
"break everywhere within a loop": "break anywhere at the top level
within a loop". A syntax for this might look like this:

  loop
    ...
  until <condition>
    ...
  until <condition>
    ...
  end loop

so one could write

  loop
    <read a value>
  until value = '0'
    <process value>
  end loop

This avoids both the obfuscation from breaking out from deeply nested
code *and* the code duplication necessary if the termination condition
is forced to the top of the loop.

To satisfy those who are concerned with making sure that the loop does
what it has to, and terminates (hi Eiffelists!), the syntax could be set
up as follows:

<loop> ::=
  from
    <loop set-up statements - syntactic sugar>
  loop
    <loop statement>
    <loop statement>
    ...
  end

<loop statement> ::=
  [invariant <condition>] -- must be true on every iteration
  [variant <expression>]  -- must decrease on every iteration
                          -- must not decrease beyond a given threshold
                          -- (this ensures that the loop terminates)
  until <expression>      -- termination condition

<loop statement> ::=
  <statement>             -- normal statements are allowed, too :)

i.e. within the loop body, an arbitrary number of
  invariant ...
  variant ...
  until ...
sequences can be placed, with invariant and variant optional. The
postcondition of the loop would be the OR of all the invariants ANDed
with their respective "until" conditions, so having too many loop exits
will make checking and understanding the loop more work, so the number
of loop exits should be small. Actually I'm not sure wether such a
syntax shouldn't be limited to a single exit - I have very rarely felt
the need for mutliple loop exits, and a bit of inconvenience in rare
cases is always worth a better language structure.

Regards,
Joachim
-- 
Please don't send unsolicited ads. (The @@ is for confusing spambots.)