Re: Exiting from a function or procedure

Re: Exiting from a function or procedure

[Andres Tarallo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]


tmoran@bix.com escribi� en mensaje ...
>>this program i have a procedure that must do something if it's parameters
>>meet a certain condition; otherwhise it must exit.
>  Do you mean the procedure must exit in the sense of return, or exit
>in the sense of stopping the program?  Your C examples suggests the
>latter.
            Thats the idea !!! when something goes wrong display a message
and stop.

>  You could use "pragma import" on the C "exit" procedure and just
>call it, exactly as your C program does.  Your code using an exception
>is fine except that it catches the exception, prints the error message,
>and then tries to drop out the bottom of the function without returning
>any value.  You probably want to add a "raise;" statement after
>the Put, to re-raise the exception.
            Ok, thanks for the advice, remember that this are my first
programas in ADA and still i'm not very familiar with the languaje.
>  Note also that some compilers are only half-smart and will give a
>warning on the construct
>[..]

>because the compiler realizes that if the program takes the "else"
>branch it will drop out the bottom of the function without returning
>any value, but the compiler doesn't realize that some_exception will
>be raised and prevent reaching the bottom of the function.
                It does give me a warning, but some thing do happen to some
C/C++ compilers so i didn't bothered in that message

                Thanks

                                            Andres Tarallo

Exiting from a function or procedure

[Andres Tarallo]

        I'm currently learning ADA, my compiler is GNAT 3.12 for Windows and
my sources are an old translation of  a book from Henry Ledgard (Dated 1983)
and the tutorials and articles I've downloaded from "The Brave ADA
Programmers Site".

        I'm currently working in a small program to handle polinomials, in
this program i have a procedure that must do something if it's parameters
meet a certain condition; otherwhise it must exit.

        What I want to do expressed i pseudo-C lenguage is something like
this:

        int sum(A, B){

                if (A == B)
                        /* Do something usefull with this  */
                else
                        exit(0);   /* something went wrong  */
                endif;
     }

    From my readings i learned that i have to do this via exceptions; the
way
to do this I achieved is:

function "+"(izq, der: in term) return term is
      aux: term;
      error_suma: exception;
      begin
         if (izq.exponente = der.exponente) then
            aux.coeficiente:= (izq.coeficiente + der.coeficiente);
            aux.exponente:= izq.exponente;
            return aux;
         else
               raise error_suma;
         end if;
         exception
                       when error_suma => Put(" ERROR !!!");
      end;


            When I compile this it compiles fine, however i get a warning
telling me that this could raise an exception during runtime.

            I'm still not very familiar with exceptions and it's handling,
Am I doing things in the right way? After displaying the message may program
will terminate?

            Thanks in advance, apologize me for my grammar and vocabulary;
english is not my mother tongue

                                        Andres Tarallo
(atarallo@chasque.apc.org)

Exiting from a function or procedure

[tmoran]

>this program i have a procedure that must do something if it's parameters
>meet a certain condition; otherwhise it must exit.
  Do you mean the procedure must exit in the sense of return, or exit
in the sense of stopping the program?  Your C examples suggests the
latter.
  You could use "pragma import" on the C "exit" procedure and just
call it, exactly as your C program does.  Your code using an exception
is fine except that it catches the exception, prints the error message,
and then tries to drop out the bottom of the function without returning
any value.  You probably want to add a "raise;" statement after
the Put, to re-raise the exception.
  Note also that some compilers are only half-smart and will give a
warning on the construct
     if ... then ... return some_value;
     else ... raise some_exception;
     end if;
   end some_function;
because the compiler realizes that if the program takes the "else"
branch it will drop out the bottom of the function without returning
any value, but the compiler doesn't realize that some_exception will
be raised and prevent reaching the bottom of the function.

Re: Exiting from a function or procedure

[Robert A Duff]

"Andres Tarallo" <atarallo@chasque.apc.org.NOSPAM> writes:

> function "+"(izq, der: in term) return term is
>       aux: term;
>       error_suma: exception;
>       begin
>          if (izq.exponente = der.exponente) then
>             aux.coeficiente:= (izq.coeficiente + der.coeficiente);
>             aux.exponente:= izq.exponente;
>             return aux;
>          else
>                raise error_suma;
>          end if;
>          exception
>                        when error_suma => Put(" ERROR !!!");
>       end;

Just raise the exception, and don't handle it.  That is, get rid of
"exception when ... ;".  Then the program will stop on that error.

>             When I compile this it compiles fine, however i get a warning
> telling me that this could raise an exception during runtime.

That's probably a different problem.  I can't tell from the excerpt you
gave.

>             I'm still not very familiar with exceptions and it's handling,
> Am I doing things in the right way? After displaying the message may program
> will terminate?

No.  After you handle an exception, the program continues on, unless you
re-raise the exception.

If you want the exception to kill the program, then just raise it.
Don't handle it.

- Bob

Re: Exiting from a function or procedure

[Robert Dewar]

In article <rm0M4.39$t25.17152@news.pacbell.net>,
  tmoran@bix.com wrote:
>   Note also that some compilers are only half-smart and will
> give a warning on the construct
>      if ... then ... return some_value;
>      else ... raise some_exception;
>      end if;
>    end some_function;
> because the compiler realizes that if the program takes the
> "else branch it will drop out the bottom of the function
> without returning any value, but the compiler doesn't realize
> that some_exception will be raised and prevent reaching the
> bottom of the function.

Hard to believe that a compiler would have a bug in it that
was this transparent ... however, the original program should
certainly generate a warning for the exception handler itself
since that will indeed raise Program_Error if executed as a
result of terminating the function without returning a value.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[Robert Dewar]

Well first of all let's start with your last statement:

> It does give me a warning, but some thing do happen to
> some C/C++ compilers so i didn't bothered in that message

Big mistake!  Never ignore warnings from GNAT.  They almost
always point to something that is wrong, and if you don't
understand them, you should get someone to help you.  Here
is a cleaned up version of your function:

  function "+" (Izq, Der:  in Term) return Term is Aux :
    Term; Error_Suma :  exception;

  begin
    if (Izq.Exponente = Der.Exponente) then
      Aux.Coeficiente := Izq.Coeficiente + Der.Coeficiente;
      Aux.Exponente   := Izq.Exponente;
      return Aux;
    else
      raise Error_Suma;
    end if;

  exception
    when error_suma =>
      Put(" ERROR !!!");
  end "+";

Now when you compile that, you get:

  20.  Put(" ERROR !!!");
       |
       >>> warning:  "return" statement missing following
           this statement
       >>> warning: Program_Error may be raised at run time

and indeed this warning is 100% accurate, and points to the
serious bug in your function.  if the line ERROR is printed,
then indeed Program_Error will be raised, and it is pretty
likely (I would guess 100% if you are a beginner) that this
was NOT intentional.

So NEVER EVER ignore warnings, consider them as errors.  In
fact you might want to use -gnatwe so the compiler will
treat them as errors enforcing this discipline.

The particular problem is that a function MUST terminate
with a return statement for ALL possible excecution paths,
and clearly your function disobeys this rule for the case
where an exception is raised.  We will address the fix
below.

But before we do, several style comments on your program,
illustrated by the clean up above.

a) indent properly, using standard style, you indented a bit
but in an inconsistent manner and indentation is one thing
that is pretty uniform in Ada, because the RM indicates a
strong recommendation for indentation.

b) use upper/lower case for identifiers as I have done
above, this is not required, but again is very much the most
common Ada standard.  There are other acceptable
capitalization styles used sometimes in Ada, but all lower
case is NOT one of them.  So get rid of that unwelcome C
habit!

c) Use a bit more white space to let the code breathe.  This
is personal taste, but again is pretty standard Ada style.

d) Repeat the name of the function on the end line

e) don't put unnecessary parentheses around expressions. In
particular avoid doing this for conditionals, that's another
C habit that need not be imported into Ada.

Those comments are style comments reflected in the cleaned
up code above.  Now for some more extensive programming
comments.

a) use comments.  Students often get into the appalling
habit of writing code first and commenting it later.  That
is terrible for three reasons:

  1. You don't get into the life long habit of always writing
  comments and if you don't get into that habit your code will
  NEVER be well documented.

  2. Going back and adding documentation later works for
  trivial programs but does not scale up, you simply cannot do
  this on large programs

  3. If you have no comments in the code as you write it, it
  makes it much harder for people to help (if you were one of
  my students I would refuse to help at all, because I would
  have told you in advance that you had better not ever show
  me uncommented code, since I won't help, but I will note it
  down and take off points for the assignment, and my TA's are
  instructed the same way :-)

b) use decent names for things, not abbreviations.  I cannot
even guess what Izq means.  One might guess that Der is
deriviative, but if so, then spell it out. It's a bit more
work to write, but in Ada, the cardinal rule is to write
code that can be easily read. A decent editor that does
name completion can help if you are a slow typist :-)

c) Perhaps this is jumping a bit far from what you know, but
likely the better code for the two assignments is

   Aux := (Coefiente => Izq.Coeficiente + Der.Coeficiente,
           Exponente => Izq.Exponente);

You can probably guess how this works just by looking at the
example. Technically it is a record aggregate, and you should
be able to find the detailed description in your Ada book. It
has the advantage of insisting that you remember to set all
fields. That does not really matter when there are only two
of them, but it can be a real advantage if there are many.

You can go a step further, just eliminate Aux
completely from your program, and write:

   return (Coefiente => Izq.Coeficiente + Der.Coeficiente,
           Exponente => Izq.Exponente);

OK, now finally back to the original issue.  You have an
error situation in this function, and the proper thing to do
is to raise an exception, but it is wrong to define this
exception INSIDE the function, why?  because the idea of an
exception is to let the CALLER decide what to do, and for
that the caller must be able to see the exception.

How to deal with this, well the function "+" must appear
inside a package, and that means the specification appears
in the package spec.  Here is an idea of how that should be
done:

function "+" (Izq, Der:  in Term) return Term;
-- This function takes two ....  and .....  and returns a
-- Term which ....  The exponents of Izq and Der must be
-- equal
--
-- Error conditions: raises Error_Suma if the exponents
-- are unequal.

I can't fill in the ....  since I don't know what this does
:-).  Just to remind you, the body now looks like:


  function "+" (Izq, Der: in Term) return Term is
  begin
    if Izq.Exponente = Der.Exponente then
      return (Coefiente => Izq.Coeficiente + Der.Coeficiente,
              Exponente => Izq.Exponente);
    else
      raise Error_Suma;
    end if;
  end "+";

Now, it is up to the caller to decide what to do about this
error.  For a simple program it may well be enough to do
nothing at all.  Now what happens if the error occurs, well
you have an unhandled exception and so the program
terminates with a nice message saying that the exception
Error_Suma was unhandled, and then you can if necessary go
into the debugger and find out why that happened.

Note how much nicer that is than the C style of returning an
error code which if you forget to check it, means that the
error is blithely ignored.  This has caused bugs in many
many C programs.  For example early versions of the Unix
editor just ignored a disk full condition, so you lost your
edited file with no warning that this had happened.

Or perhaps the CALLER will have an exception handler to
detect the error and take appropriate action.

One further point.  In some real large programs, there is a
protocol of logging errors, and that may mean it is
appropriate to modify your function as follows:

  function "+" (Izq, Der: in Term) return Term is
  begin
    if Izq.Exponente = Der.Exponente then
      return (Coefiente => Izq.Coeficiente + Der.Coeficiente,
              Exponente => Izq.Exponente);
    else
      raise Error_Suma;
    end if;

  exception
    when Error_Suma =>
      Error_Log ("error occured in "+" with args ....");
    raise;
  end "+";

Here the raise with no argument (often called a reraise),
reraises the same exception, so that the caller can deal
with it as appropriate.

Finally a quick note about the advice you received to
interface the C function exit.  This was non-Ada advice,
and shows the risk of getting advice from CLA, you can often
get correct advice which answers the wrong problem.

Interfacing exit answered the question of "how can I exactly
duplicate the style and content of my C program in Ada?"
But that's not what we are interested in doing here since
you are learning Ada :-)

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[Ken Garlington]

Everything Dr. Dewar said, plus this:

* Ledgard's book was pretty minimal with respect to explaining Ada83, and of
course it doesn't address all of the capabilities now available in the
current version of Ada (and supported by GNAT). When you get past the
basics, try to find some time to explore the "bigger picture" with a more
recent reference.

* You've defined what should happen if your exponents are unequal. Have you
considered what (if anything) should happen if the sum of the coefficients
will be too big to fit in the range of the result? See the description of
CONSTRAINT_ERROR in sections 10.1 and 10.3 of Ledgard.

Also, one other note: For GNAT, the statement "the program terminates with a
nice message saying that the exception... was unhandled" is probably true.
However, I don't think the standard requires "a nice message." If you want
your program to behave nicely (and consistently) when compiled with any
compiler, you will need to define that behavior within the program.

Re: Exiting from a function or procedure

[tmoran]

> So NEVER EVER ignore warnings, consider them as errors.  In
> fact you might want to use -gnatwe so the compiler will
> treat them as errors enforcing this discipline.

This is not always a good idea.  For instance
     if OK then
       return some_value;
     else
       Log_And_Raise_Error;
     end if;
   end some_function;
is a perfectly legitimate paradigm in Ada that would become
illegal in Gnat with -gnatwe, since the compiler doesn't know
that Log_And_Raise_Error will never return.

Re: Exiting from a function or procedure

[Ray Blaak]

tmoran@bix.com writes:
> > So NEVER EVER ignore warnings, consider them as errors.  In
> > fact you might want to use -gnatwe so the compiler will
> > treat them as errors enforcing this discipline.
> 
> This is not always a good idea.  For instance
>      if OK then
>        return some_value;
>      else
>        Log_And_Raise_Error;
>      end if;
>    end some_function;
> is a perfectly legitimate paradigm in Ada that would become
> illegal in Gnat with -gnatwe, since the compiler doesn't know
> that Log_And_Raise_Error will never return.

I always put in a dummy return in these cases, just to avoid such warnings, and
for safety if the log routine ever *doesn't* raise an exception (e.g. maybe due
to some maintenance change in the future).

Of course, I also prefer a single return point, so I would have written:

      result := default_value;
      if OK then
        result := ok_value;
      else
        Log_And_Raise_Error;
      end if;
      return result;
    end some_function;

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Exiting from a function or procedure

[David Starner]

On 22 Apr 2000 12:33:32 -0700, Ray Blaak <blaak@infomatch.com> wrote:
>tmoran@bix.com writes:
>> > So NEVER EVER ignore warnings, consider them as errors.  In
>> > fact you might want to use -gnatwe so the compiler will
>> > treat them as errors enforcing this discipline.
>> 
>> This is not always a good idea.  For instance
>>      if OK then
>>        return some_value;
>>      else
>>        Log_And_Raise_Error;
>>      end if;
>>    end some_function;
>> is a perfectly legitimate paradigm in Ada that would become
>> illegal in Gnat with -gnatwe, since the compiler doesn't know
>> that Log_And_Raise_Error will never return.
>
>I always put in a dummy return in these cases, just to avoid such warnings, and
>for safety if the log routine ever *doesn't* raise an exception (e.g. maybe due
>to some maintenance change in the future).

Of course, that masks a bug. Log_And_Raise_Error is defined to raise an 
exception - if it doesn't then it's buggy. Either that, or the maintenance
programmer should have fixed every use of Log_And_Raise_Error - and a dummy
return is unlikely to be the correct fix. At least in developement, raising
Program_Error is a good result.

-- 
David Starner - dstarner98@aasaa.ofe.org
Finger dvdeug@x8b4e53cd.dhcp.okstate.edu for more information.
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Exiting from a function or procedure

[Pablo Moisset]

Hi

> b) use decent names for things, not abbreviations.  I cannot
> even guess what Izq means.  One might guess that Der is
> deriviative, but if so, then spell it out. It's a bit more
> work to write, but in Ada, the cardinal rule is to write
> code that can be easily read. A decent editor that does
> name completion can help if you are a slow typist :-)

It was easy for me to interpret Izq and Der. They mean
'izquierdo' and 'derecho' (left and right in spanish). :)
Nevertheless I think the rules you stated are right.

Pablo

Re: Exiting from a function or procedure

[Robert Dewar]

In article <BKmM4.214$nb6.208368@news.pacbell.net>,
  tmoran@bix.com wrote:
> > So NEVER EVER ignore warnings, consider them as errors.  In
> > fact you might want to use -gnatwe so the compiler will
> > treat them as errors enforcing this discipline.
>
> This is not always a good idea.  For instance
>      if OK then
>        return some_value;
>      else
>        Log_And_Raise_Error;
>      end if;
>    end some_function;
> is a perfectly legitimate paradigm in Ada that would become
> illegal in Gnat with -gnatwe, since the compiler doesn't know
> that Log_And_Raise_Error will never return.


Two responses:

I still prefer to work with -gnatwe, and then use pragma
Warnings (Off) to locally suppress a warning that can be
ignored, always adding a comment as to why this is being done.

Second, in this particular case, that is exactly why we added
the pragma No_Return to GNAT. When using GNAT, if you have
a procedure like Log_And_Raise_Error, then you declare that
procedure with pragma No_Return, and two things happen, first
the compiler checks that there are no return statements in
Log_And_Raise_Error, second the warning is suppressed at the
point of call.

The trouble with leaving warnings in your code is that you can
easily get into the habit of ignoring warnings, and we see many
people generating lots of extra work for themselves this way.
GNAT goes to a considerable effort to generate all kinds of
useful warnings -- we often get the reaction when people port
to GNAT from another compiler that they discover latent bugs
in their code from these warnings.

So getting into the habit of never ignoring warnings and
insisting on warning-free code is a good one, and I repeat
my advice to follow this approach. Using -gnatwe (as we do
when we compile GNAT) is a good way to enforce this discipline.

Of course the pragmas Warnings (Off) and No_Return are GNAT
specific, but there are several points to be made there:

1. Unrecognized pragmas are ignored, it is VERY unlikely that
any other compiler recognizes these pragmas unless it implements
them.

2. Warnings are pretty compiler dependent anyway, GNAT tends to
be pretty aggressive in looking for opportunities to generate
warnings. Note that some compilers don't even generate warnings
at all for missing blocked return paths in functions.

3. In several cases, pragmas initially introduced into GNAT are
being considered for more general adoption (pragma Unsuppress is
an example). Perhaps pragma Warnings (Off) and No_Return are
other candidates.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[Robert Dewar]

In article <39024681.D36A4477@usc.edu>,
  Pablo Moisset <pmoisset@usc.edu> wrote:

> It was easy for me to interpret Izq and Der. They mean
> 'izquierdo' and 'derecho' (left and right in spanish). :)
> Nevertheless I think the rules you stated are right.


OK, well probably they should be spelled out, unless these
abbreviations are *so* universally understood that they
cause no problems. For instance I do not mind Lo and Hi
as abbreviations for Low and High, since they are not
going to cause any confusion.

Note that even in the RM, some abbreviations are considered
acceptable, e.g. IO for Input_Output, since it would really
be a bit of a nuisance to have to write:

with Text_Input_Output; use Text_Input_Output;

all the time, and if anything IO is *more* familiar than the
full phrase.

So the rule against language abbreviations is not absolute, and
if I had been more fluent in Spanish (I recognize the full
words, but did not click to the abbreviations :-), it might well
be that these are in the Lo,Hi category.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[tmoran]

>The trouble with leaving warnings in your code is that you can
>easily get into the habit of ignoring warnings, and we see many
  Agreed.

>Of course the pragmas Warnings (Off) and No_Return are GNAT
>specific, but there are several points to be made there:
  In this case, I could dispense with the Gnat warning by using
pragma Warnings(Off) or No_Return, but instead I'd just get new
warnings, about unrecognized pragmas, from other compilers.  So in
either case warnings will be raised, at least until all (or at least
most) Ada compilers implement one or both of those pragmas.

  In this specific case, rewriting usually removes the warning,
though it may confuse the maintenance programmer who worries
"what value is returned when things are not OK?".  It's also
subject to the previously noted problem "what happens if there's
a bug and Log_And_Raise_Error actually *does* return?"
     if not OK then
       Log_And_Raise_Error;
     end if;
     return some_value;
   end some_function;

> GNAT tends to be pretty aggressive in looking for opportunities to
> generate warnings.  Note that some compilers don't even ...
  A classic tradeoff in this case between Type 1 and Type 2
error probabilities.

Re: Exiting from a function or procedure

[Robert Dewar]

In article <vzJM4.1253$t25.356170@news.pacbell.net>,
  tmoran@bix.com wrote:
>      if not OK then
>        Log_And_Raise_Error;
>      end if;
>      return some_value;
>    end some_function;

I find the above code a very poor choice, precisely because,
as Tom notes, it will worry a maintenance programmer as to
what is going on! Far better is

      if not OK then
        Log_And_Raise_Error;
        raise Program_Error;
      end if;

or if you want to take the effort

      if not OK then
        Log_And_Raise_Error;
        raise Impossible_Exception_Cannot_Be_Raised;

Still for those using GNAT, use the opportunity to learn about
pragma No_Return, since it is a very clear way of documenting
the special case of a procedure that never returns.

By the way, I think it is a terrible design choice in Ada 95
that Raise_Exception can return to the caller. We end up special
casing this in GNAT to avoid the warning in this case (raising
Program_Error seems reasonable enough if Raise_Exception returns
and the return path is unblocked.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[Robert Dewar]

In article <vzJM4.1253$t25.356170@news.pacbell.net>,
  tmoran@bix.com wrote:
>   A classic tradeoff in this case between Type 1 and Type 2
> error probabilities.

Actually I see no trade off here, there is no advantage in a
compiler NOT warning in cases which clearly warrant a warning.

We find surprisingly few cases of warnings that are not
warranted, and they are easily dealt with.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[tmoran]

> >   A classic tradeoff in this case between Type 1 and Type 2
> > error probabilities.
>
> Actually I see no trade off here, there is no advantage in a
> compiler NOT warning in cases which clearly warrant a warning.

If a situation "clearly" warrants a warning, then it warrants a
warning.  But there are cases where the "clearly warrants" is
disputable.  One reason for deciding not to have the compiler
issue a particular warning might be:

>The trouble with leaving warnings in your code is that you can
>easily get into the habit of ignoring warnings, and we see many

Re: Exiting from a function or procedure

[Robert Dewar]

In article <ITRM4.955$7N2.399746@news.pacbell.net>,
  tmoran@bix.com wrote:
> If a situation "clearly" warrants a warning, then it warrants
> a warning.  But there are cases where the "clearly warrants"
> is disputable.

General claims like this are a bit unconvincing, an example
would be helpful. As I said earlier, I do not know of any
warnings in GNAT where there is a good argument for omitting
the warning (or they would not be there). On the other hand,
we get quite a bit of input from users asking for additional
warnings.

> One reason for deciding not to have the
> compiler issue a particular warning might be:
>
> >The trouble with leaving warnings in your code is that you
> >can easily get into the habit of ignoring warnings, and we
> > see many

Actually, our experience is most often that people ignore
warnings which ARE useful, and very often we get examples of
code that is full of warnings, ALL of which represent real
problems, and the programmer has just ignored them all on the
grounds that warnings are usually useless. My point here is
that, again in our experience, the warnings in GNAT are
definitely useful and should NOT be ignored. I am definitely
not making a point about warnings in general. I am quite aware
that some compilers generate a lot of useless warnings!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exiting from a function or procedure

[Scott Ingram]

Robert Dewar wrote:

> b) use decent names for things, not abbreviations.  I cannot
> even guess what Izq means.  One might guess that Der is
> deriviative, but if so, then spell it out. It's a bit more
> work to write, but in Ada, the cardinal rule is to write
> code that can be easily read. A decent editor that does
> name completion can help if you are a slow typist :-)
> 

Izq, short for Izquierda (Left,) and Der, short for Derecho (Right.)
While these abbreviations are fairly common in Spanish and Portuguese,
they do make it extremely difficult for others to read the code.
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory