Re: labeling (was: partitioning (was: Future))

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

We veered off on another topic, but while there
I discovered another possibility for labeling:

    case Animal is

       ......

    end case (Animal);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must be semantically identical to case selector.


    if Animal in Mammal then

       .....

    elsif Animal in Reptile then

       .....

    else

       .....

    end if (Animal in Mammal | Animal in Reptile | not);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must be semantically identical to if condition.
    -- If elsif's are present, contents of paren may be semantically
    -- identical to ONE OR MORE of the conditions.  If a straight
    -- else is present, the " | not " is optional


    procedure P (Param : in Param_Type) is

       .....

    begin (P (Param : in Param_Type))

       .....

    exception (P (Param : in Param_Type))

       .....

    end P (Param : in Param_Type);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must conform.


I intend to "formally" submit this
as a proposed improvement.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: labeling (was: partitioning (was: Future))

[Christoph Grein]

Wes, excuse me for the harsh words, but this is absolute nonsense in my eyes :-(
And I _bet_ you won't get any support in Ada-Comment.


> 
>     case Animal is
> 
>        ......
> 
>     end case (Animal);
> 
>     -- Contents of parens have no effect on behavior
>     -- of program.  Constitutes compiler-checked comment,
>     -- nothing more.  Parens and contents optional.  If present,
>     -- contents must be semantically identical to case selector.
> 
> 
>     if Animal in Mammal then
> 
>        .....
> 
>     elsif Animal in Reptile then
> 
>        .....
> 
>     else
> 
>        .....
> 
>     end if (Animal in Mammal | Animal in Reptile | not);
> 
>     -- Contents of parens have no effect on behavior
>     -- of program.  Constitutes compiler-checked comment,
>     -- nothing more.  Parens and contents optional.  If present,
>     -- contents must be semantically identical to if condition.
>     -- If elsif's are present, contents of paren may be semantically
>     -- identical to ONE OR MORE of the conditions.  If a straight
>     -- else is present, the " | not " is optional
> 
> 
>     procedure P (Param : in Param_Type) is
> 
>        .....
> 
>     begin (P (Param : in Param_Type))
> 
>        .....
> 
>     exception (P (Param : in Param_Type))
> 
>        .....
> 
>     end P (Param : in Param_Type);
> 
>     -- Contents of parens have no effect on behavior
>     -- of program.  Constitutes compiler-checked comment,
>     -- nothing more.  Parens and contents optional.  If present,
>     -- contents must conform.
> 
> 
> I intend to "formally" submit this
> as a proposed improvement.
> 
> -- 
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> Wes, excuse me for the harsh words, but this is absolute nonsense in my eyes :-(
> And I _bet_ you won't get any support in Ada-Comment.

Well, if it (or anything like it) becomes a formal proposal,
you and all that agree with you can say so to the reviewers.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: labeling (was: partitioning (was: Future))

[Michal Nowak]

On 2002-03-13 at 08:42 Wes Groleau wrote:

>We veered off on another topic, but while there
>I discovered another possibility for labeling:
>
>    case Animal is
>
>       ......
>
>    end case (Animal);
>
>    -- Contents of parens have no effect on behavior
>    -- of program.  Constitutes compiler-checked comment,
>    -- nothing more.  Parens and contents optional.  If present,
>    -- contents must be semantically identical to case selector.

What about:

    case Animal is

       ......

    end case Animal;

with the same rules as for ending procedure/function?

>    if Animal in Mammal then
>
>       .....
>
>    elsif Animal in Reptile then
>
>       .....
>
>    else
>
>       .....
>
>    end if (Animal in Mammal | Animal in Reptile | not);

This looks short and terse when there are not too much branches
(and is not necessary then, becaue it should be possible to
see all branches on one screen). When there will be more branches,
this may grow to some extraordinary size, affecting readibility
(in my opinion).

>    procedure P (Param : in Param_Type) is
>
>       .....
>
>    begin (P (Param : in Param_Type))
>
>       .....
>
>    exception (P (Param : in Param_Type))
>
>       .....
>
>    end P (Param : in Param_Type);
>
>    -- Contents of parens have no effect on behavior
>    -- of program.  Constitutes compiler-checked comment,
>    -- nothing more.  Parens and contents optional.  If present,
>    -- contents must conform.

Please no! Why put parameter list (or this proposal is for only
one-parameter?) to every element of comb? Why parameters near
exception handlig? And what, when there will be three or more 
parameters? This won't be readable I think.

Just my comments,
Mike

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> >    end case (Animal);
> 
> What about:
> 
>     end case Animal;
> 
> with the same rules as for ending procedure/function?

That was somebody's earlier proposal.  Someone had some reason
for proposing adding the parens.  I might have been one or both
somebodies--I can't remember.  I also don't remember the reason
for using parentheses. (Yeah, I know the archives are available.)

> >    end if (Animal in Mammal | Animal in Reptile | not);
> 
> This looks short and terse when there are not too much branches
> (and is not necessary then, becaue it should be possible to
> see all branches on one screen). When there will be more branches,
> this may grow to some extraordinary size, affecting readibility
> (in my opinion).

If you put in everything allowed, yes.  But I suggested that you
don't have to put in all branches--in fact, you don't have to put
in any.  Besides, if you have a zillion eslifs you probably should
have used a case statement.

> >    end P (Param : in Param_Type);
> >
> >    -- Contents of parens have no effect on behavior
> >    -- of program.  Constitutes compiler-checked comment,
> >    -- nothing more.  Parens and contents optional.  If present,
> >    -- contents must conform.
> 
> Please no! Why put parameter list (or this proposal is for only
> one-parameter?) to every element of comb? Why parameters near
> exception handlig? And what, when there will be three or more
> parameters? This won't be readable I think.

Again, I said the parameter list is _optional_ but if used, must
conform.
Might help navigation when the subprogram identifier is overloaded,
but is OPTIONAL.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: labeling (was: partitioning (was: Future))

[Marin David Condic]

This is not very orthogonal with the rest of Ada and is potentially quite
awkward since "case (Animal)..." is really an expression rather than an
identifier for a structure. It would be much more orthogonal to do something
like:

Animal: case (Some_Expression) is
...
end case Animal ;

That is consistent with the loop and block statements.

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/


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C90DD8A.21D57CD2@despammed.com...
>
>
> > >    end case (Animal);
> >
> > What about:
> >
> >     end case Animal;
> >
> > with the same rules as for ending procedure/function?
>
> That was somebody's earlier proposal.  Someone had some reason
> for proposing adding the parens.  I might have been one or both
> somebodies--I can't remember.  I also don't remember the reason
> for using parentheses. (Yeah, I know the archives are available.)
>

Re: labeling (was: partitioning (was: Future))

[Tarjei T. Jensen]

Wes Groleau wrote
> We veered off on another topic, but while there
> I discovered another possibility for labeling:
>
>     case Animal is
>
>        ......
>
>     end case (Animal);

I would prefer

   case Animal label animal is


   ......

    end animal;

    if Animal in Mammal label animal_if
    then

    ...
    end animal_if;

or possibly more readable:

    label animal_if
    if Animal in Mammal
    then
    ...
    end animal_if;

Prepending the statement which one want a named end for is perhaps easier to
accomodate?

The label would not be available for anything else but end verification, so
it would not be a problem that it has the same name as a variable or type.
In other words; labels would have their own name space.

Re: labeling (was: partitioning (was: Future))

[Christoph Grein]

This is getting more and more absurd. Why not stick to the current syntax:

[statement_identifier:] xxx
  ...
end xxx [identifier];

where xxx stands for:
  Ada95: loop_statement, block_statement
  Ada0Y: case_statement, if_statement, select_statement

Why on earth introduce new syntax? Please get the RM and see how it solves the 
present cases, and then try to take the syntax over to new cases. If you really 
want to have a chance of getting this thru, this is the way to go.

The ARG really has enough urgent problems to solve, and I bey they are reluctant 
to handle any such weird proposals.

> I would prefer
> 
>    case Animal label animal is
> 
> 
>    ......
> 
>     end animal;
> 
>     if Animal in Mammal label animal_if
>     then
> 
>     ...
>     end animal_if;
> 
> or possibly more readable:
> 
>     label animal_if
>     if Animal in Mammal
>     then
>     ...
>     end animal_if;
> 
> Prepending the statement which one want a named end for is perhaps easier to
> accomodate?
> 
> The label would not be available for anything else but end verification, so
> it would not be a problem that it has the same name as a variable or type.
> In other words; labels would have their own name space.
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> >     case Animal is
> >
> >        ......
> >
> >     end case (Animal);
> 
> I would prefer
> 
>    case Animal label animal is


In my opinion, the two best proposals so far are

   Label:
      case/if expression is/then
         .....
      end case/if Label;

AND

   case/if expression is/then
       .....
   end case/if (expression);

The first is simpler, but the second has more flexibility.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: labeling (was: partitioning (was: Future))

[Richard Riehle]

In my original comment about the value of labels for
many Ada constructs, I did not anticipate the many
variations on the theme that might be concocted.

My comments were a complaint that curly braces in
the C family of languages would be more useful if they
permitted scope delimiting labels that could be checked
by the compiler.    We wouldn't need these everywhere,
only where they would add clarity.

Ada already provides this feature for adding clarity.
And we can insert it anywhere we wish in long blocks
of code (not that I am recommending long blocks of code).
It is nice that the labels are checked by the compiler as
well as improving readability by humans, programmers
included.

I really don't think it is necessary to add new labeling
features to the language for selection statements, as
some have suggested.   For me, end case and end if
are quite enough.

However, it is sometimes useful to create a begin..end
block with a label for especially long constructs.   For
example,

        case X is
             when Sigma => Sigma_Process:
                                       begin
                                            sequence-of-statements
                                       end Sigma_Process;
            when Theta =>  Theta_Process:
                                      begin
                                           handled-sequence-of-statements
                                      exception
                                           sequence-of-statements
                                      end Theta_Process;
        end case;

If it is a really long case statement, the case statement can
be wrapped in a labeled begin..end block.

However, I don't favor this for compilers that support pragma
inline well.   Instead, the above code can be made more effective
by promoting it to a private child package, or enclosing the long
begin..end statements into nested inlined procedures.  Even the
case statement itself can be promoted to an inlined procedure.

        procedure P is
             -- local declarations
             procedure Theta_Process is ... begin ... end Theta_Process;
             pragma Inline(Theta_Process);
             procedure Sigma_Process is ... begin ... end Sigma_Process;
             pragma Inline(Sigma_Process);
             -- more declarations
       begin
            case X is
                when Sigma => Sigma_Process;
                when Theta =>  Theta_Process;
            end case;
      end P;

Re: labeling (was: partitioning (was: Future))

[Christoph Grein]

> From: Wes Groleau <wesgroleau@despammed.com>
> In my opinion, the two best proposals so far are
> 
>    Label:
>       case/if expression is/then
>          .....
>       end case/if Label;
> 
> AND
> 
>    case/if expression is/then
>        .....
>    end case/if (expression);
> 
> The first is simpler, but the second has more flexibility.

Really, where is the _inflexibility_ of the first form? Because you have to 
invent a name for the label?

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> > In my opinion, the two best proposals so far are
> >
> >    Label:
> >       case/if expression is/then
> >          .....
> >       end case/if Label;
> >
> > AND
> >
> >    case/if expression is/then
> >        .....
> >    end case/if (expression);
> >
> > The first is simpler, but the second has more flexibility.
> 
> Really, where is the _inflexibility_ of the first form? Because you have to
> invent a name for the label?

The first form is simpler because there's only two options.

The second is more flexible because for an if statement
of N branches, there are 2**N options.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau