Re: Continue/next statement, static variables, and block comments

Re: Continue/next statement, static variables, and block comments

[Michael Feldman]

In article <4ssspn$501@umbc10.umbc.edu>,
Mordechai T. Abzug <mabzug1@umbc.edu> wrote:

>Another problem is static variables, ie. variables which are only visible
>inside a function but retain their value across multiple invocations of the
>funcyion.  Again, I can model this (putting the function and the variable
>in their own dummy package), but don't know a way to do it naturally.

It's perfectly natural to encapsulate state information in an enclosing 
unit of some kind. Indeed, it's how OO languages do it. You have a problem
only because you're thinking in terms of isolated functions instead of
encapsulsated sets of functions operating on variables (objects, whatever).
>
>One last question (well, this one's more in the way of a gripe, since I'm
>fairly certain I'm not missing anythhing here): no block commenting.  Line
>comments are a superior way of commenting when documentation is the only
>thing you have in mind, but if you want to comment out a large section of
>code, you want block comments.  My makeshift here is an "if false
>then. . . endif;" pair, but of course, it only works for executable
>statements, not declarations.   <sigh>.

How about something revolutionary: an editor that lets you insert
-- at the begining of a range of lines. :-)

BTW - suppose you have a 24-line editor window and then use C-or Pascal-
style commenting to "comment out" a 50-line block of code? Then you  
scroll the middle 24 lines into your window. How do you know whether
it's active code, or commented out? _That's_ the real virtue of line
commenting!

Mike Feldman

Continue/next statement, static variables, and block comments

[Mordechai T. Abzug]

Many languages provide a means to bypass the current iteration of a loop
without terminating the loops, ie. C's continue or Perl's next.  Ada
doesn't seem to have one, despite having an exit statement, which is
extremely similar in nature to the continue.  Is there something I'm
missing?  I could, of course, model "continue" using if's, but a genuine
continue or next is more natural, reads better, and works better in case
statements.  Anyone know of a suitable substitute?

Another problem is static variables, ie. variables which are only visible
inside a function but retain their value across multiple invocations of the
funcyion.  Again, I can model this (putting the function and the variable
in their own dummy package), but don't know a way to do it naturally.

One last question (well, this one's more in the way of a gripe, since I'm
fairly certain I'm not missing anythhing here): no block commenting.  Line
comments are a superior way of commenting when documentation is the only
thing you have in mind, but if you want to comment out a large section of
code, you want block comments.  My makeshift here is an "if false
then. . . endif;" pair, but of course, it only works for executable
statements, not declarations.   <sigh>.

So, anyone have any constructive suggestions?  Please don't tell me I
should just do this in C -- for various reasons, Ada makes sense for the
project as a whole.  I just have a few problems with it. 

-- 
			  Mordechai T. Abzug
http://umbc.edu/~mabzug1   mabzug1@umbc.edu     finger -l mabzug1@gl.umbc.edu
In God we trust.  All others pay cash.

Re: Continue/next statement, static variables, and block comments

[Kevin J. Weise]

mabzug1@umbc.edu (Mordechai T. Abzug) wrote:
>Many languages provide a means to bypass the current iteration of a loop
>without terminating the loops, ie. C's continue or Perl's next.  Ada
>doesn't seem to have one, despite having an exit statement, which is
>extremely similar in nature to the continue.  Is there something I'm
>missing?  I could, of course, model "continue" using if's, but a genuine
>continue or next is more natural, reads better, and works better in case
>statements.  Anyone know of a suitable substitute?

Without wishing to start a religious war (please!), I believe the language
designers figured that the equivalent of the C "continue" was unnecessary.
Indeed, one could argue that

     loop
        ...
        if condition then
           ...
        end if;
     end loop;

is more readable than

     loop
        ...
        if condition then continue;
        ...
     end loop;

since it is more apparent that there are statements affected by the "if".
Of course, one could argue that badly indented source code could be just
as easily misread, although semantically equivalent; or that 

         exit when condition;

is just as guilty.  Mea culpa.  This is probably just one of those
"personal preferences".  I like the "exit when ...", but don't care 
much for the C "continue".

>
>Another problem is static variables, ie. variables which are only visible
>inside a function but retain their value across multiple invocations of 
>the funcyion.  Again, I can model this (putting the function and the 
>variable in their own dummy package), but don't know a way to do it 
>naturally.

One merely needs to follow scope.  You want a variable to retain its value
between invocations of a subprogram, make it non-local to that subprogram.
If the subprogram is a library unit, you don't have much choice in 
Ada83 except to make your static variables visible in a package.  The 
downside to this approach is that anything else that "withs" this package 
can change those variables without the subprogram knowing about it.  In 
Ada95, you could potentially make the subprogram a child of the package so 
that the static variables don't need to be visible.  There's also some 
aspect of Ada95 that I haven't yet investigated where packages can be made 
private.  I assume this means one can control which library units can have 
access to another library unit's interface.

>One last question (well, this one's more in the way of a gripe, since I'm
>fairly certain I'm not missing anythhing here): no block commenting.  
>Line comments are a superior way of commenting when documentation is the 
>only thing you have in mind, but if you want to comment out a large 
>section of code, you want block comments.  My makeshift here is an "if 
>false then. . . endif;" pair, but of course, it only works for executable
>statements, not declarations.   <sigh>.

Well, the latter portion of this gripe is true; and I have also wished
for something along the lines of a compiler switch to accept or ignore
code.  But then again, I've seen C code where such practices were so 
abused that the product was grotesquely difficult to read & understand.  
In a similar vein, I've seen too much confusing code where the author(s) 
commented out blocks of code & it wasn't apparent to me if it was old code
that needed to be deleted (but wasn't because the "programmer" wasn't sure
if that was the needed correction) or anticipated upgrade code for future
capabilities.  In any case, block comments of this nature are difficult 
to detect the further apart the beginning and end of the block are from 
each other.  Of course, I understand the intent is to clean it up when
the software is "finished" or "ready"; quite often this is done.  Quite
often, it isn't done, too.  Nested blocks in both situations are 
nightmares for someone unfamiliar with the code.  This is not just a 
C-ism, either; I used to get dinged by this in other peoples' SIMULA code 
when I was in college.  

I believe that if one needs to retain segments of code for historical 
reasons, then a CM tool, such as DEC VAX/CMS or Unix CVS/RCS is a far 
better mechanism for doing so.  (There are better CM tools,  of course, 
but a simple checkout/checkin tool should suffice).

I prefer to use tools & stand by the Ada solution. 
>
>So, anyone have any constructive suggestions?  Please don't tell me I
>should just do this in C -- for various reasons, Ada makes sense for the
>project as a whole.  I just have a few problems with it. 

My best suggestion (and I hope this is taken in the good spirit in which 
it is intended) is to make an Ada solution, rather than a C solution in 
Ada syntax.  The practices you mention are considered "poor form", even
though they are widely used with other languages.

>
>-- 
>			  Mordechai T. Abzug
>http://umbc.edu/~mabzug1   mabzug1@umbc.edu     finger -l mabzug1@gl.umbc.edu
>In God we trust.  All others pay cash.
---------------------------------------------------------------------
Kevin J. Weise             email:  kweise@sed.redstone.army.mil
COLSA Corporation          voice:  (205) 842-9083
Huntsville, AL

.. standard disclaimers apply

Re: Continue/next statement, static variables, and block comments

[Robert A Duff]

In article <4t2ohl$brq@michp1.redstone.army.mil>,
Kevin J. Weise <kweise@c3i-ccmail.sed.redstone.army.mil> wrote:
>While I haven't changed my mind about this, I have looked at the ada-mode 
>for emacs, and found that you can comment and uncomment regions of code.  
>Certainly, you have your supporters in the Ada community, Mr. Abzug, and 
>they have provided you with a solution!  If you aren't familiar with it, 
>emacs is a great tool (esp. as augmented by the ada mode, v2.12) and I 
>highly recommend it; but it does require some getting used to.  I hope you 
>can utilize it in your programming environment.

The nice thing about the Ada-and-Emacs-combined solution is that (1)
it's easy to comment out code, and (2) it's easy to see that the code is
commented out, because every line is marked with "--", so you don't have
to know that 50 lines above your editor window, there's a begin-comment
marker.

IMHO, commented-out code should be a very temporary thing.  I've been
known to comment out code, but I always do something about it within a
small number of days.  I don't think commented-out code is acceptable in
a final product delivered to a customer.  And even in the temporary
case, there ought to be a comment explaining the commenting-out.

- Bob

Re: Continue/next statement, static variables, and block comments

[Kevin J. Weise]

Previously, mabzug1@umbc.edu (Mordechai T. Abzug) wrote (with deletions):
>>One last question (well, this one's more in the way of a gripe, since I'm
>>fairly certain I'm not missing anythhing here): no block commenting.  
>>Line comments are a superior way of commenting when documentation is the 
>>only thing you have in mind, but if you want to comment out a large 
>>section of code, you want block comments.  

.. and I responded (with deletions):

>
>               ... I've seen too much confusing code where the author(s) 
>commented out blocks of code & it wasn't apparent to me if it was old code
>that needed to be deleted (but wasn't because the "programmer" wasn't sure
>if that was the needed correction) or anticipated upgrade code for future
>capabilities.  In any case, block comments of this nature are difficult 
>to detect the further apart the beginning and end of the block are from 
>each other.   
>
>I believe that if one needs to retain segments of code for historical 
>reasons, then a CM tool, such as DEC VAX/CMS or Unix CVS/RCS is a far 
>better mechanism for doing so.  

While I haven't changed my mind about this, I have looked at the ada-mode 
for emacs, and found that you can comment and uncomment regions of code.  
Certainly, you have your supporters in the Ada community, Mr. Abzug, and 
they have provided you with a solution!  If you aren't familiar with it, 
emacs is a great tool (esp. as augmented by the ada mode, v2.12) and I 
highly recommend it; but it does require some getting used to.  I hope you 
can utilize it in your programming environment.

---------------------------------------------------------------------
Kevin J. Weise             email:  kweise@sed.redstone.army.mil
COLSA Corporation          voice:  (205) 842-9083
Huntsville, AL

. standard disclaimers apply

Re: Continue/next statement, static variables, and block comments

[Dale Stanbrough]

Robert A Duff writes:

"(2) it's easy to see that the code is
 commented out, because every line is marked with "--", so you don't have
 to know that 50 lines above your editor window, there's a begin-comment
 marker."
 
This can be less of a problem with editors that have colour coding for the
comments.

Dale