an infinate loop

an infinate loop

[Beau]

Hey I am in an infinate loop and don't understand why. here is my problem to
understan exactly what is going down:
assume that a set of sentences is to be processed. Each sentence consists of
a sequence of words, seperated by one or more blank spaces. Write a program
that will read these sentences and count the number of words that have one
letter, two letter, and so on, up to ten letters.
It was working until I put in a loop to catch the end of line because if the
sentence was more than a line, then the words on the end would be counted
together. now the program does the first line perfect and then falls into
the "never-ending" loop. enclosed is the adb file and the data file. put the
file anywhere just type the path in when asked.
----------
here is the adb file:
WITH Ada.Text_IO;
USE Ada.Text_IO;
WITH Ada.Integer_Text_IO;
USE Ada.Integer_Text_IO;


PROCEDURE Word_Count2 IS

--declarations needed are as follows

--variables for file input

Infile : Ada.Text_IO.File_Type;

FileName : String(1..80); --for the opening of the file

Length : Natural;

--variables for the counters

WordLength : Natural := 0;
WordCount1 : Natural := 0;
WordCount2 : Natural := 0;
WordCount3 : Natural := 0;
WordCount4 : Natural := 0;
WordCount5 : Natural := 0;
WordCount6 : Natural := 0;
WordCount7 : Natural := 0;
WordCount8 : Natural := 0;
WordCount9 : Natural := 0;
WordCount10 : Natural := 0;


--variable for the character

Letter : Character;

Pause : Character; --pause to see the results


BEGIN --Word_Count

--print program header

Put(Item => "Word Count Program. This program will read in ");
New_Line;
Put(Item => "from a text file a set of sentences and count the ");
New_Line;
Put(Item => "amount of words that had 1 letter, 2 letters, ");
New_Line;
Put(Item => "3 letters... up to ten letters.");
New_Line(Spacing => 2);

--prompt for and read the name of the path for the input file

Put(Item => "Please key in the path of the input file ");
Put(Item => "for the program:");
New_Line;
Ada.Text_IO.Get_Line(Item => FileName, Last => Length);
New_Line;
Ada.Text_IO.Open(File => Infile,
       Mode => Ada.Text_IO.In_File,
       Name => FileName(1..Length));

--An outer loop to catch the end of file

LOOP
 EXIT WHEN Ada.Text_IO.End_of_File(File => Infile);
  Get(File => Infile, Item => Letter);
  Put(Item => "This sentence contained the following: ");
  New_Line;
  LOOP
     EXIT WHEN Ada.Text_IO.End_of_Line(File => Infile);

-- a nested loop to catch the end of sentence. The end of a sentence can
--be found by looking for .,?,and !

 LOOP
  EXIT WHEN Letter = '.' OR ELSE Letter = '?' OR ELSE Letter = '!';

--another nested post-test loop to catch the end of a word. The end of
--a word can be found by looking for blank spaces

       LOOP
     CASE Letter IS --if the character variable was a actual letter
        --then add one to wordlength

        WHEN 'a'..'z' |'A'..'Z' =>
           WordLength := WordLength + 1;
        WHEN OTHERS =>
           NULL;
          END CASE;

     Get(File => Infile, Item => Letter);

     EXIT WHEN Letter = ' ' OR ELSE Letter = '.'
           OR ELSE Letter = '?' OR ELSE Letter = '!';

  END LOOP;

  --CASE statement to add one to the variable for the number
  --letters in each word

  CASE WordLength IS

     WHEN 10 =>
   WordCount10 := WordCount10 + 1;
     WHEN 9 =>
      WordCount9 := WordCount9 + 1;
     WHEN 8 =>
      WordCount8 := WordCount8 + 1;
     WHEN 7 =>
   WordCount7 := WordCount7 + 1;
     WHEN 6 =>
   WordCount6 := WordCount6 + 1;
     WHEN 5 =>
   WordCount5 := WordCount5 + 1;
     WHEN 4 =>
   WordCount4 := WordCount4 + 1;
     WHEN 3 =>
   WordCount3 := WordCount3 + 1;
     WHEN 2 =>
   WordCount2 := WordCount2 + 1;
     WHEN 1 =>
   WordCount1 := WordCount1 + 1;
     WHEN OTHERS =>
   NULL;

  END CASE;

  WordLength := 0;

 END LOOP;

 --print the number of words that each had 1,2,3,4...10 letters in them

 Put(Item => "The amount of words containing 1 letter was: ");
 Put(Item => WordCount1, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 2 letter was: ");
 Put(Item => WordCount2, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 3 letter was: ");
 Put(Item => WordCount3, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 4 letter was: ");
 Put(Item => WordCount4, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 5 letter was: ");
 Put(Item => WordCount5, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 6 letter was: ");
 Put(Item => WordCount6, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 7 letter was: ");
 Put(Item => WordCount7, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 8 letter was: ");
 Put(Item => WordCount8, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 9 letter was: ");
 Put(Item => WordCount9, Width => 2);
 New_Line;
 Put(Item => "The amount of words containing 10 letter was: ");
 Put(Item => WordCount10, Width => 2);
 New_Line(Spacing => 3);

      Put(Item => "Please press a key to continue: ");
      Get(Item => Pause);
      New_Line(Spacing => 2);

      WordCount1 := 0;
      WordCount2 := 0;
      WordCount3 := 0;
      WordCount4 := 0;
      WordCount5 := 0;
      WordCount6 := 0;
      WordCount7 := 0;
      WordCount8 := 0;
      WordCount9 := 0;
      WordCount10 := 0;

  END LOOP;

  Ada.Text_IO.Skip_Line(File => Infile, Spacing => 1);

END LOOP;

Ada.Text_IO.Close(Infile);

END Word_Count2;

-----------------------------
here is the data file:

Hello how are you?
I hope this program works.
Maybe it will work because
if it does not, I am in trouble.
Oh well. GoodBye.
--
~Beau~
beau@hiwaay.net

Re: an infinate loop

[DuckE]

Hint:
  A file containing the text:

.a

Gives the same error.

SteveD

"Beau" <beau@hiwaay.net> wrote in message
news:tks6i2llqcla15@corp.supernews.com...
> Hey I am in an infinate loop and don't understand why. here is my problem
to
> understan exactly what is going down:
> assume that a set of sentences is to be processed. Each sentence consists
of
> a sequence of words, seperated by one or more blank spaces. Write a
program
> that will read these sentences and count the number of words that have one
> letter, two letter, and so on, up to ten letters.
> It was working until I put in a loop to catch the end of line because if
the
> sentence was more than a line, then the words on the end would be counted
> together. now the program does the first line perfect and then falls into
> the "never-ending" loop. enclosed is the adb file and the data file. put
the
> file anywhere just type the path in when asked.
> ----------
> here is the adb file:
> WITH Ada.Text_IO;
> USE Ada.Text_IO;
> WITH Ada.Integer_Text_IO;
> USE Ada.Integer_Text_IO;
>
>
> PROCEDURE Word_Count2 IS
>
> --declarations needed are as follows
>
> --variables for file input
>
> Infile : Ada.Text_IO.File_Type;
>
> FileName : String(1..80); --for the opening of the file
>
> Length : Natural;
>
> --variables for the counters
>
> WordLength : Natural := 0;
> WordCount1 : Natural := 0;
> WordCount2 : Natural := 0;
> WordCount3 : Natural := 0;
> WordCount4 : Natural := 0;
> WordCount5 : Natural := 0;
> WordCount6 : Natural := 0;
> WordCount7 : Natural := 0;
> WordCount8 : Natural := 0;
> WordCount9 : Natural := 0;
> WordCount10 : Natural := 0;
>
>
> --variable for the character
>
> Letter : Character;
>
> Pause : Character; --pause to see the results
>
>
> BEGIN --Word_Count
>
> --print program header
>
> Put(Item => "Word Count Program. This program will read in ");
> New_Line;
> Put(Item => "from a text file a set of sentences and count the ");
> New_Line;
> Put(Item => "amount of words that had 1 letter, 2 letters, ");
> New_Line;
> Put(Item => "3 letters... up to ten letters.");
> New_Line(Spacing => 2);
>
> --prompt for and read the name of the path for the input file
>
> Put(Item => "Please key in the path of the input file ");
> Put(Item => "for the program:");
> New_Line;
> Ada.Text_IO.Get_Line(Item => FileName, Last => Length);
> New_Line;
> Ada.Text_IO.Open(File => Infile,
>        Mode => Ada.Text_IO.In_File,
>        Name => FileName(1..Length));
>
> --An outer loop to catch the end of file
>
> LOOP
>  EXIT WHEN Ada.Text_IO.End_of_File(File => Infile);
>   Get(File => Infile, Item => Letter);
>   Put(Item => "This sentence contained the following: ");
>   New_Line;
>   LOOP
>      EXIT WHEN Ada.Text_IO.End_of_Line(File => Infile);
>
> -- a nested loop to catch the end of sentence. The end of a sentence can
> --be found by looking for .,?,and !
>
>  LOOP
>   EXIT WHEN Letter = '.' OR ELSE Letter = '?' OR ELSE Letter = '!';
>
> --another nested post-test loop to catch the end of a word. The end of
> --a word can be found by looking for blank spaces
>
>        LOOP
>      CASE Letter IS --if the character variable was a actual letter
>         --then add one to wordlength
>
>         WHEN 'a'..'z' |'A'..'Z' =>
>            WordLength := WordLength + 1;
>         WHEN OTHERS =>
>            NULL;
>           END CASE;
>
>      Get(File => Infile, Item => Letter);
>
>      EXIT WHEN Letter = ' ' OR ELSE Letter = '.'
>            OR ELSE Letter = '?' OR ELSE Letter = '!';
>
>   END LOOP;
>
>   --CASE statement to add one to the variable for the number
>   --letters in each word
>
>   CASE WordLength IS
>
>      WHEN 10 =>
>    WordCount10 := WordCount10 + 1;
>      WHEN 9 =>
>       WordCount9 := WordCount9 + 1;
>      WHEN 8 =>
>       WordCount8 := WordCount8 + 1;
>      WHEN 7 =>
>    WordCount7 := WordCount7 + 1;
>      WHEN 6 =>
>    WordCount6 := WordCount6 + 1;
>      WHEN 5 =>
>    WordCount5 := WordCount5 + 1;
>      WHEN 4 =>
>    WordCount4 := WordCount4 + 1;
>      WHEN 3 =>
>    WordCount3 := WordCount3 + 1;
>      WHEN 2 =>
>    WordCount2 := WordCount2 + 1;
>      WHEN 1 =>
>    WordCount1 := WordCount1 + 1;
>      WHEN OTHERS =>
>    NULL;
>
>   END CASE;
>
>   WordLength := 0;
>
>  END LOOP;
>
>  --print the number of words that each had 1,2,3,4...10 letters in them
>
>  Put(Item => "The amount of words containing 1 letter was: ");
>  Put(Item => WordCount1, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 2 letter was: ");
>  Put(Item => WordCount2, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 3 letter was: ");
>  Put(Item => WordCount3, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 4 letter was: ");
>  Put(Item => WordCount4, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 5 letter was: ");
>  Put(Item => WordCount5, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 6 letter was: ");
>  Put(Item => WordCount6, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 7 letter was: ");
>  Put(Item => WordCount7, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 8 letter was: ");
>  Put(Item => WordCount8, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 9 letter was: ");
>  Put(Item => WordCount9, Width => 2);
>  New_Line;
>  Put(Item => "The amount of words containing 10 letter was: ");
>  Put(Item => WordCount10, Width => 2);
>  New_Line(Spacing => 3);
>
>       Put(Item => "Please press a key to continue: ");
>       Get(Item => Pause);
>       New_Line(Spacing => 2);
>
>       WordCount1 := 0;
>       WordCount2 := 0;
>       WordCount3 := 0;
>       WordCount4 := 0;
>       WordCount5 := 0;
>       WordCount6 := 0;
>       WordCount7 := 0;
>       WordCount8 := 0;
>       WordCount9 := 0;
>       WordCount10 := 0;
>
>   END LOOP;
>
>   Ada.Text_IO.Skip_Line(File => Infile, Spacing => 1);
>
> END LOOP;
>
> Ada.Text_IO.Close(Infile);
>
> END Word_Count2;
>
> -----------------------------
> here is the data file:
>
> Hello how are you?
> I hope this program works.
> Maybe it will work because
> if it does not, I am in trouble.
> Oh well. GoodBye.
> --
> ~Beau~
> beau@hiwaay.net
>
>
>

Re: an infinate loop

[Ted Dennison]

In article <tks6i2llqcla15@corp.supernews.com>, Beau says...
>
>Hey I am in an infinate loop and don't understand why. here is my problem to

Look for a big red sign that says "EXIT".

Oh, you mean your *code*? :-)

For one thing, you have 4 nested loops in one big honking routine. For some
people that may be no big deal, but to me its unspeakably ugly. Consider at
least putting the 2 inner loops in their own routine.

For another, it is generally considered very bad form to use an unnamed exit
statement inside of a nested loop. Its too easy for the reader to loose track of
which loop is being broken out of, particularly on a largish set of loops like
you have here. 

For another, most of your "exit" statements are all at the tops of the loops. In
those cases you should probably reverse the test logic and use "while" loops
instead. 

For another, the innermost loop seems to have no code to handle the end of the
file:

>--another nested post-test loop to catch the end of a word. The end of
>--a word can be found by looking for blank spaces
>       LOOP
>     CASE Letter IS --if the character variable was a actual letter
>        --then add one to wordlength
>
>        WHEN 'a'..'z' |'A'..'Z' =>
>           WordLength := WordLength + 1;
>        WHEN OTHERS =>
>           NULL;
>          END CASE;
>
>     Get(File => Infile, Item => Letter);
>
>     EXIT WHEN Letter = ' ' OR ELSE Letter = '.'
>           OR ELSE Letter = '?' OR ELSE Letter = '!';
>
>  END LOOP;


Lastly, and most importantly, you are going through *way* too much work for this
task. You could be doing this entire job with one loop. It looks like you are
trying to somehow code a state machine using each loop to reperesent a state.
Loops are a pretty poor mechanism for representing state machine states. Instead
you should just encode the state in some variable, and do an "if" or "case" on
it inside your main character processing loop. Actually, the variable that keeps
track of which character in the word you are on could probably be made to do the
job. The other way to do state machines is to use "goto" for the state
transitions, but this looks like a school assignment, and I doubt your
instructor wants to see that (although some might like it).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: an infinate loop

[C. Bauman]

If you consider that detecting end-of-line is to be equivalent to detecting
a space character, I think you'll find that loop is inappropriately placed.
Since you don't specify how the infinite loop manifests itself, I can't
guarantee this will fix it, but it should help if I point out that you only
need one loop for this.  Most of what you are doing with loops can be
handled in the case statement.

i.e. in pseudo code:

main loop
  exit on eof
  if eol then letter = ' ' else letter = get(char)
  case letter
    'A'..'z'   -  update wordlength
    ' '         -  update wordcount of wordlength, reset wordlegnth
    '.','?','!' -  output sentence data, reset wordcounts, reset wordlength
  end case
end loop
if sentence not terminated correctly, output remaining sentence data.

I'm not sure how much Ada programming you've had, but using arrays and
subprocedures can reduce the typing and keep the listing readable.

-CB


"Beau" <beau@hiwaay.net> wrote in message
news:tks6i2llqcla15@corp.supernews.com...
> Hey I am in an infinate loop and don't understand why. here is my problem
to
> understan exactly what is going down:
> assume that a set of sentences is to be processed. Each sentence consists
of
> a sequence of words, seperated by one or more blank spaces. Write a
program
> that will read these sentences and count the number of words that have one
> letter, two letter, and so on, up to ten letters.
> It was working until I put in a loop to catch the end of line because if
the
> sentence was more than a line, then the words on the end would be counted
> together. now the program does the first line perfect and then falls into
> the "never-ending" loop. enclosed is the adb file and the data file. put
the
> file anywhere just type the path in when asked.

listing snipped.

Re: an infinate loop

[Jeffrey Carter]

Ted Dennison wrote:
> 
> For another, most of your "exit" statements are all at the tops of the loops. In
> those cases you should probably reverse the test logic and use "while" loops
> instead.

This is bad advice. The form that uses positive logic is best.

exit when End_Of_File;

uses positive logic, and is better than

while not End_Of_File loop

which uses negative logic. All of the exits in this program use positive
logic. In general, exit tends to use positive logic and while tends to
use negative logic.

However, when exiting from nested loops, it is a good idea to name your
loops and use the loop names on the exit statements and the end loop
statements. This badly formatted program is hard enough to understand
without trying to figure out which end loop corresponds to which exit.

At the "Ada Launch" (1980 Dec 10), Ichbiah, Barnes, and Firth introduced
the recently renamed Ada language (MIL-STD 1815, formerly Green, now
known as Ada 80) to the world. They said "while" was in the language
primarily to support translation from languages such as Pascal, and
advised using the "loop ... exit when" format in new code.

-- 
Jeffrey Carter

Re: an infinate loop

[Ted Dennison]

In article <3B4F2962.25BB60FF@boeing.com>, Jeffrey Carter says...
>
>Ted Dennison wrote:
..
>This is bad advice. The form that uses positive logic is best.
>
loop
>exit when End_Of_File;
>
>uses positive logic, and is better than
>
>while not End_Of_File loop
>
>which uses negative logic. All of the exits in this program use positive
>logic. In general, exit tends to use positive logic and while tends to
>use negative logic.

True. As a seperate issue, I'd say it is better when you can rearrange the
condition so it uses positive logic. Unfortunately, you can't always do that,
and this is one of those cases. So you have to look at the overall effect one
way vs. the other and ask yourself which is clearer.

>At the "Ada Launch" (1980 Dec 10), Ichbiah, Barnes, and Firth introduced
>the recently renamed Ada language (MIL-STD 1815, formerly Green, now
>known as Ada 80) to the world. They said "while" was in the language
>primarily to support translation from languages such as Pascal, and
>advised using the "loop ... exit when" format in new code.

Interesting. Do you have a reference for this (or perhaps you were there)? It
seems like rather bad logic, as you can clearly construct any of the other kinds
of loops with "loop" and "exit". I do remember hearing (second hand. I'm not
trying to claim I was there either) a quote similar to this about "goto". There
are those here who would dispute its validity in that context too though.

The issue with "for" and "while" is that they are more controlled, constrained
variants of "loop". As such, they are useful for designating that this is a loop
that behaves in one of those controlled, constrained type of ways. If it is just
"loop", then the reader has to assume its control structure could be pretty much
*anything*, and go reading through all the code inside to see what it actually
is. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: an infinate loop

[chris.danx]

> > For another, most of your "exit" statements are all at the tops of the
loops. In
> > those cases you should probably reverse the test logic and use "while" loops
> > instead.
>
> This is bad advice. The form that uses positive logic is best.

?

What is positive/negative logic?

Do you mean

while y is true loop is negative logic,

but loop ... exit when x is true is positive logic?

I just don't see it?


> exit when End_Of_File;
>
> uses positive logic, and is better than
>
> while not End_Of_File loop
>
> which uses negative logic. All of the exits in this program use positive
> logic. In general, exit tends to use positive logic and while tends to
> use negative logic.

I don't get it.  Can you explain this to me?  All my tutors and lecturers say
while is better than loop for most occasions.  All the books i've read say the
same.

Is this just a matter of style?



[ I did wonder about Beau's use of loop exit and he/she (I don't know if that's
a masculine name or a feminine name) said the tutors recommend loop over while,
which I thought curious since I've always learned it the other way.]


> At the "Ada Launch" (1980 Dec 10), Ichbiah, Barnes, and Firth introduced
> the recently renamed Ada language (MIL-STD 1815, formerly Green, now
> known as Ada 80) to the world. They said "while" was in the language
> primarily to support translation from languages such as Pascal, and
> advised using the "loop ... exit when" format in new code.

Oh, so Ada might have ended up wirth no while had there been no concern for
translation between Ada and other languages?


TBH: I prefer the info at the top of structures so i don't have go far to find
it.  Getting the conditions right is easier (for me) if this is the case.
procedures, functions, while, for, discriminant records/tasks, etc all have the
conditions and info at the top, which I find better for me.  It's just a
preference, and I have no difficulty with other ppl using different schemes.
I'd just like to know what all the fuss is about i guess.

Chris

Re: an infinate loop

[Jeffrey Carter]

Ted Dennison wrote:
> 
> >At the "Ada Launch" (1980 Dec 10), Ichbiah, Barnes, and Firth introduced
> >the recently renamed Ada language (MIL-STD 1815, formerly Green, now
> >known as Ada 80) to the world. They said "while" was in the language
> >primarily to support translation from languages such as Pascal, and
> >advised using the "loop ... exit when" format in new code.
> 
> Interesting. Do you have a reference for this (or perhaps you were there)? It
> seems like rather bad logic, as you can clearly construct any of the other kinds
> of loops with "loop" and "exit". I do remember hearing (second hand. I'm not
> trying to claim I was there either) a quote similar to this about "goto". There
> are those here who would dispute its validity in that context too though.

My first introduction to Ada was watching videotapes of the Ada Launch
presentations by IBF and reading copies of their slides. I have no idea
how you could get this today. They did say that goto was in the language
primarily to support translation from languages such as FORTRAN. Lucky
for the state machine with goto people that they were interested in
supporting translation from other languages.

-- 
Jeffrey Carter

Re: an infinate loop

[Jeffrey Carter]

"chris.danx" wrote:
> 
> What is positive/negative logic?

Negative logic contains negations (not x). Positive logic does not.
Studies indicate that people understand positive logic better than
negative logic.

> Oh, so Ada might have ended up wirth no while had there been no concern for
> translation between Ada and other languages?

Possibly. You'd have to ask Jean Ichbiah.

-- 
Jeffrey Carter

Re: an infinate loop

[Robert Dewar]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B4F764E.DF2DB15@boeing.com>...

> Studies indicate that people understand positive logic better than
> negative logic.

Without a reference, such an argument is simply an appeal to authority,
a well known debating technique, but not one to be paid much attention
to. Now *with* a reference, it would be an interesting contribution.

To me in english is it just as clear to say

"if you are free today, can you ...

"if you are not busy today, can you ...

And it would be interesting to see "studies* refuting this ...

Negative Logic (was: Re: an infinate loop)

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B4F764E.DF2DB15@boeing.com>...
> 
> > Studies indicate that people understand positive logic better than
> > negative logic.
> 
> Without a reference, such an argument is simply an appeal to authority,
> a well known debating technique, but not one to be paid much attention
> to. Now *with* a reference, it would be an interesting contribution.

I agree. Sometimes, though, one doesn't have the reference available. I
recall this being mentioned in the Ada Quality and Style Guide; a quick
look at AdaIC shows

5.5.4 Positive Forms of Logic 

     guideline 

     Avoid names and constructs that rely on the use of negatives.
     Choose names of flags so they represent states that can be used in
positive form. 

     example 

     Use: 

     if Operator_Missing then

     rather than either: 

     if not Operator_Found then

     or: 

     if not Operator_Missing then

     rationale 

     Relational expressions can be more readable and understandable when
stated in a positive form.

Not exactly a reference, but perhaps a little better than proof by
blatant assertion.

On Google I also found

http://www.seas.gwu.edu/~mfeldman/cs1book/fk3-im/chap7.html

Instructor's Manual for M.B. Feldman and E.B. Koffman, Ada 95 Problem
Solving and Program Design, 3rd edition.

with the statement

The material on loops other than FOR loops is heavily revised in this
edition, to present general loops before WHILE loops. This reflects the
observation that beginners deal more naturally with "positive logic" --
stating a positive condition to exit a loop ...

Happy Bastille Day.

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail

Re: an infinate loop

[Darren New]

Ted Dennison wrote:
> >while not End_Of_File loop

> True. As a seperate issue, I'd say it is better when you can rearrange the
> condition so it uses positive logic. Unfortunately, you can't always do that,
> and this is one of those cases. 

function Still_More_File (...) : Boolean is
begin
  return not End_Of_File(...);
end;

Wouldn't that do it?  (I always thought it was kind of odd to provide an
EOF function instead of a Theres_Still_Some_Left function.)

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
          Only a WIMP puts wallpaper on his desktop.

Re: an infinate loop

[Matthias Kretschmer]

> job. The other way to do state machines is to use "goto" for the state
> transitions, but this looks like a school assignment, and I doubt your
> instructor wants to see that (although some might like it).


I do not think "goto" is the right way to do this nowadays. Even if your 
language supports goto statement (but in the case of Ada it was 
implemented to have programs/algorithms from other languages like 
FORTRAN easily ported).

Using case statements and loops should be the "better" way to do this. 
It should be easier to understand the program.



m.k.

Re: an infinate loop

[Philip Anderson]

Robert Dewar wrote:
> 
<snip request for a reference, which would be interesting>

> To me in english is it just as clear to say
> 
> "if you are free today, can you ...
> 
> "if you are not busy today, can you ...
> 
> And it would be interesting to see "studies* refuting this ...


In this case with a simple negative I don't think there is a difference,
but it changes with more complicated conditions.  Consider:

"If you are not stress-free ..."
v
"If you are stressed ..."

or

"If it is not raining or snowing ..." where English has no rule that
"not" has precedence over "or" or vice versa.


Also, what is the reply to "are you not busy today?"

"Yes [I am not busy today]" or "no [I am not busy today]"?

where I believe the expectation is different to speakers of different
languages.


On the other hand, a clear neagtive like "not empty" is better than an
unclear positive like "partly-filled" - and even "positive" can be
ambiguous to French-speakers!


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: an infinate loop

[Ted Dennison]

In article <3B50D895.EB3C192@san.rr.com>, Darren New says...
>
>Ted Dennison wrote:
>> >while not End_Of_File loop

>function Still_More_File (...) : Boolean is
.
>Wouldn't that do it?  (I always thought it was kind of odd to provide an
>EOF function instead of a Theres_Still_Some_Left function.)

Yeah, you could make a special function to do it. But "not" is probably just as
clear as doing that. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: an infinate loop

[Marin David Condic]

IIRC, the argument was that other languages had attempted to eliminate the
goto in their design, but that typically the first enhancement made was to
throw the goto back in. The argument followed that Ada could try to spit
into the wind and eliminate the goto for all sorts of computer-sciency
reasons, but inevitably enough people would want it for enough good reasons
that it should just get included in the language from the start. As with
other language features, Ada at least attempted to make the goto more safe
by restricting some of the things you could jump into and out of. On the
whole, I think it was pretty successful - you almost never hear of anybody
saying "I'd love to use Ada, but because of all the restrictions on the goto
statement, I just can't make it work for my app..." :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3B4F758B.197CA145@boeing.com...
>
> My first introduction to Ada was watching videotapes of the Ada Launch
> presentations by IBF and reading copies of their slides. I have no idea
> how you could get this today. They did say that goto was in the language
> primarily to support translation from languages such as FORTRAN. Lucky
> for the state machine with goto people that they were interested in
> supporting translation from other languages.
>

Re: an infinate loop

[Marin David Condic]

IMHO, the "negative logic" is not confusing until you start mixing up more
than one condition. Saying "not Daytime" is pretty easily understood as
equivalent to "Nighttime", but when you start with things like "not Daytime
and not Full_Moon or not Month_With_An_R_In_It", it is probably better to
avoid the negative logic and state the condition positively.

In that sense "not End_Of_File" is fine with me and pretty clearly indicates
when I should stop.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:cWB47.20903$Kf3.261918@www.newsranger.com...
> Yeah, you could make a special function to do it. But "not" is probably
just as
> clear as doing that.
>

Re: an infinate loop

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> <snip good advice>
> For another, most of your "exit" statements are all at the tops of the loops. In
> those cases you should probably reverse the test logic and use "while" loops
> instead. 

This is a matter of personal style. For myself, I _much_ prefer "exit"
statments to "while" statements. I just find it clearer.

> <snip more good advice>

-- 
-- Stephe

Re: Negative Logic (was: Re: an infinate loop)

[Robert Dewar]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3B50706F.D24FB0ED@acm.org>...

OK, so both "references" are nothing more than restatements of what
might well be a complete myth!

Re: Negative Logic (was: Re: an infinate loop)

[Robert Dewar]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3B50706F.D24FB0ED@acm.org>...
> The material on loops other than FOR loops is heavily revised in this
> edition, to present general loops before WHILE loops. This reflects 
> the observation that beginners deal more naturally with "positive 
> logic" stating a positive condition to exit a loop ...


Note that I agree that *other things being equal* conditions which
have a NOT are more complicated to understand than those that don't
(any extra operator adds complexity, other things being equal).

The trouble is that things are typically NOT equal, and what worries
me about a rule like this is it will cause people to recast their
conditions, using Demorgan's laws or whatever, to desparately avoid
a NOT, resulting in something more complex.

Sort of like the situation where convoluted boolean flags are added
in a desparate attempt to avoid a goto that would be the most natural
way of writing the code, e.g. to reflect a loop continue statement in
a language (like Ada :-) with no continue statement in loops.

Of course AQ&S is just intended to be guidelines anyway, but I far
too often see people turning these AQ&S guidelines into rules :-(

Re: an infinate loop

[Matthias Kretschmer]

Marin David Condic wrote:

> IIRC, the argument was that other languages had attempted to eliminate the
> goto in their design, but that typically the first enhancement made was to
> throw the goto back in. The argument followed that Ada could try to spit
> into the wind and eliminate the goto for all sorts of computer-sciency
> reasons, but inevitably enough people would want it for enough good reasons
> that it should just get included in the language from the start. As with
> other language features, Ada at least attempted to make the goto more safe
> by restricting some of the things you could jump into and out of. On the
> whole, I think it was pretty successful - you almost never hear of anybody
> saying "I'd love to use Ada, but because of all the restrictions on the goto
> statement, I just can't make it work for my app..." :-)
> 


It is possible to program without using an goto at all (see W.A.Wulf: 
"Programming without goto" or D.E.Knuth and R.W.Floyd (1971): "Notes on 
avoiding goto statement") - and this should be the right way. Jumps/goto 
make the whole thing very unreadable I think and it is difficult to 
prove the correctness. Proving the correctness of 
algorithms/subprograms/programs is maybe unusual (or done by only a 
few), but if you are sure that your way of doing it, is the right way, 
it should be easy to prove. Unproven code just waits for its counterexample.

Once someone involved in the Ada design in the beginnig told me, that 
the goto statement was mainly implemented to make the language more 
attractive to people who do not want to live without.

Re: an infinate loop

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> IIRC, the argument was that other languages had attempted to eliminate the
> goto in their design, but that typically the first enhancement made was to
> throw the goto back in. The argument followed that Ada could try to spit
> into the wind and eliminate the goto for all sorts of computer-sciency
> reasons, but inevitably enough people would want it for enough good reasons
> that it should just get included in the language from the start. As with
> other language features, Ada at least attempted to make the goto more safe
> by restricting some of the things you could jump into and out of. 

I think that Ada avoided the goto by making the goto "labels" so ugly, that
any self respecting programmer would do his best to avoid it!

Warren.

> On the
> whole, I think it was pretty successful - you almost never hear of anybody
> saying "I'd love to use Ada, but because of all the restrictions on the goto
> statement, I just can't make it work for my app..." :-)
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: an infinate loop

[Marin David Condic]

I have not used a goto in any language since at least 1983 - maybe longer,
but prior to that I had a job maintaining ancient Cobol code and I might
have actually used a goto to be consistent with some existing code. I'm
aware of how little necessity there is for the goto as a result of that
practical experience. :-)

I know arguments were made for including the goto in Ada along a variety of
lines. Some of it had to do with automatic translation of existing things
being more difficult if there was no goto. Some of it was undoubtedly to
make it appeal to people who didn't know how to live without one. Some of it
was, as I said, because there was evidence indicating that goto's got put
into languages that tried to leave them out - sooner or later people come up
with some practical consideration that makes it worth having them in the
language. Whatever the reasons, I have no objections to the presence of a
goto in Ada - I just believe they should be used sparingly, if at all...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Matthias Kretschmer" <McCratch@gmx.net> wrote in message
news:3B546F9D.4030809@gmx.net...
>
>
> It is possible to program without using an goto at all (see W.A.Wulf:
> "Programming without goto" or D.E.Knuth and R.W.Floyd (1971): "Notes on
> avoiding goto statement") - and this should be the right way. Jumps/goto
> make the whole thing very unreadable I think and it is difficult to
> prove the correctness. Proving the correctness of
> algorithms/subprograms/programs is maybe unusual (or done by only a
> few), but if you are sure that your way of doing it, is the right way,
> it should be easy to prove. Unproven code just waits for its
counterexample.
>
> Once someone involved in the Ada design in the beginnig told me, that
> the goto statement was mainly implemented to make the language more
> attractive to people who do not want to live without.
>

Re: an infinate loop

[Ted Dennison]

In article <9j1u8a$863$1@nh.pace.co.uk>, Marin David Condic says...
>
>I have not used a goto in any language since at least 1983 - maybe longer,

Before this year, I hadn't used one since I quit using BASIC 16 years ago. I had
an occasion to write a small lexer in C (the classic "state machine" app), so I
tried it out that way.

I have to say that the result wasn't pretty. However, the alternatives; using a
huge multiply nested "if", or a "switch" in a loop with an enumeration
designating the state, would have been just as ugly, and would have taken more
CPU to achieve that equal uglyness. I could easily see where someone familar
with reading state machine code could make a case that the goto version was
indeed easier to read, but it still wasn't as readable as I generally like to
see my code be. I think the basic problem is that state-machine control flow
itself is ugly, and there just is no pretty way to show it.

So while I can't agree that "goto" inarguably makes this particular algorithm
look better, it at least doesn't make it worse, and it performs it slightly
quicker. I'm not sure that would normally be enough to justify its inclusion in
the language. However, I'd observe that this issue comes up a lot more for
compiler writers than for the rest of us, and compiler writers did create this
language. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: an infinite [was: infinate] loop

[AG]

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B52B331.7B059E30@amsjv.com...
> Robert Dewar wrote:
> >
> <snip request for a reference, which would be interesting>
>
> > To me in english is it just as clear to say
> >
> > "if you are free today, can you ...
> >
> > "if you are not busy today, can you ...
> >
> > And it would be interesting to see "studies* refuting this ...
>
>
> In this case with a simple negative I don't think there is a difference,
> but it changes with more complicated conditions.  Consider:
>
> "If you are not stress-free ..."
> v
> "If you are stressed ..."
>
> or
>
> "If it is not raining or snowing ..." where English has no rule that
> "not" has precedence over "or" or vice versa.

To quote my favorite old example of that:

I couldn't fail to disagree with you less...

Re: an infinate loop

[Matthias Kretschmer]

Ted Dennison wrote:

> So while I can't agree that "goto" inarguably makes this particular algorithm
> look better, it at least doesn't make it worse, and it performs it slightly
> quicker. I'm not sure that would normally be enough to justify its inclusion in
> the language. However, I'd observe that this issue comes up a lot more for
> compiler writers than for the rest of us, and compiler writers did create this
> language. :-)
>

Another way of implementing a state machine would be to make an array of subprogram
access types to subprograms handling the different states. This could be faster
than using case with using the current state as an index to the array. This should
be nearly as fast as using goto, just it doesn't use fixed jump-points. But if you
just implement features because of speed enhancements of special problems, than you
should implement everything including an assembler. Goto doesn't make it look
worse, but make it may be more complicated. Using for each state a seperate
subprogram would be probably make the whole stuff more appealing to the eyes of
other people.

But in the other hand, just use aflex or something like that for processing strings
and do not think about the implementation. As long as the aflex-programmers did
their job well, one do not have to worrie how it is implemented and how to change
the specific implementation, just using it is enough.

But this leads to another way of implementing a state machine. Using an approach
similar to aflex and the like. Implementing the statemachine with rules that apply
to different states and having just one subprogram processing the rules stored for
example in an array of records or something like that. The array can be filled at
run-time by processing a file (which could lead to the problem of using a state
machine for this parser :-)) or by a constant array hardcoded in the program.

mfg Matthias

Re: an infinate loop

[Ted Dennison]

In article <3B56C6B2.559EE5F3@bsdger.org>, Matthias Kretschmer says...
>Another way of implementing a state machine would be to make an array of 
>subprogram access types to subprograms handling the different states. This 
>could be faster than using case with using the current state as an index to 
>the array. This should be nearly as fast as using goto, just it doesn't use 
>fixed jump-points. But if you just implement features because of speed 
>enhancements of special problems, than you should implement everything 
>including an assembler. Goto doesn't make it look worse, but make it may be 
>more complicated. Using for each state a seperate subprogram would be probably 
>make the whole stuff more appealing to the eyes of other people.

To pull this off, you'd still need a loop around everything so you could iterate
through the array. This is essentially the same as a case statement in a loop,
except that you are replacing the "case" with an array. Another difference is
that you now have subprogram call overhead for each state change.

Often jump-table type code can be replaced with dynamic distpatch too, and that
allows users to arbitrarily modify the routines in the jump-table without
modifying the existing (debugged) sources. If this line of reasoning in lexical
analysis interests you, you really ought to look into OpenToken, which
implements it. See http://www.telepath.com/dennison/Ted/OpenToken/OpenToken.html