Re: code partitioning (was: Future with Ada)

Re: code partitioning (was: Future with Ada)

[Wes Groleau]

> I *think* we're on the same wavelength. 

Yes, I agree.  No splitting things up except on
"logical" boundaries so that the parts can have
meaningful names.

> And I would find attempts to go through gyrations to make this shorter just
> to fit some kind of "Don't make a case statement longer than twentysomething
> lines" rule a bit silly. My original illustration was to show a

Without actually endorsing this, here's a sort of
borderline situation:

   case Animal is

      when Horse | Tiger   | Elephant | Whale | Mouse |
           Dog   | Gorilla | Platypus | Koala | Dingo   =>

         Classify_Mammal (Animal);

      when Lizard | Snake | Alligator | Tortoise =>

         Classify_Reptile (Animal);

      ......

      when others =>

         Classify_Some_Really_Wierd_Thing (Animal);

                        -- gratuitous demo of
   end case (Animal);   -- yet another way of
                        -- naming a case statement
      
  -- to bring it back to the original topic
  -- now that I've updated the subject line  :-)

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

Re: code partitioning (was: Future with Ada)

[Marin David Condic]

Well, yea, I could see that - even breaking it up into a "when mammal ...
when others..." case in something like this. It kind of goes to my original
point: You ought to keep ifs and cases short and as unnested as may make
sense for the problem at hand, but don't go crazy.

You've got to use some judgment, thinking "Shortness and non-nestedness are
good things taken from The Book Of Devoutly To Be Desired Results, but lets
not forget that the spirit of the law is to make things readable and
comprehensible" If statements nest for three or four levels or span several
dozen lines, yet remain comprehensible (being a natural reflection of the
problem at hand) and breaking them up would require unnatural acts of
contortion, then don't fight it. Programming is often an "art" that requires
an "artistic eye" rather than an exact science... much like other writing
and communication skills.

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:3C8E3110.F36F2DC8@despammed.com...
>
> Without actually endorsing this, here's a sort of
> borderline situation:
>
>    case Animal is
>
>       when Horse | Tiger   | Elephant | Whale | Mouse |
>            Dog   | Gorilla | Platypus | Koala | Dingo   =>
>
>          Classify_Mammal (Animal);
>
>       when Lizard | Snake | Alligator | Tortoise =>
>
>          Classify_Reptile (Animal);
>
>       ......
>
>       when others =>
>
>          Classify_Some_Really_Wierd_Thing (Animal);
>
>                         -- gratuitous demo of
>    end case (Animal);   -- yet another way of
>                         -- naming a case statement
>
>   -- to bring it back to the original topic
>   -- now that I've updated the subject line  :-)
>

Re: code partitioning (was: Future with Ada)

[Christoph Grein]

> From: Wes Groleau <wesgroleau@despammed.com>
>    case Animal is
        snip
>    end case (Animal);   -- yet another way of
>                         -- naming a case statement

Nonono

case [expression] is
  ...
end case;

So how about

case Some*weird*and/long+expression is
  ...
end case Some*weird*and/long+expression;

Re: code partitioning (was: Future with Ada)

[Larry Kilgallen]

In article <mailman.1015999862.11331.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.com> writes:
>> From: Wes Groleau <wesgroleau@despammed.com>
>>    case Animal is
>         snip
>>    end case (Animal);   -- yet another way of
>>                         -- naming a case statement
> 
> Nonono
> 
> case [expression] is
>   ...
> end case;
> 
> So how about
> 
> case Some*weird*and/long+expression is
>   ...
> end case Some*weird*and/long+expression;

I prefer:

	case Some*weird*and/long+expression is
	  ...
	end case;	-- Some*weird*and/long+expression

since it requires no vendor action and I have resigned myself to
the fact that successful programming can never be entirely devoid
of self-discipline.

I have found that so long as _every_ end case has such a comment,
I am unlikely to get them interchanged.

Re: code partitioning (was: Future with Ada)

[Wes Groleau]

> case [expression] is
>   ...
> end case;
> 
> So how about
> 
> case Some*weird*and/long+expression is
>   ...
> end case Some*weird*and/long+expression;

Exactly.  "Animal" is just a wierd and short expression.
See my other post for more details.

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

Re: code partitioning (was: Future with Ada)

[Wes Groleau]

> I prefer:
> 
>         case Some*weird*and/long+expression is
>           ...
>         end case;       -- Some*weird*and/long+expression
> 
> since it requires no vendor action and I have resigned myself to
> the fact that successful programming can never be entirely devoid
> of self-discipline.

That's the argument C fans use for rejecting Ada.

We should check everything ourselves, we should never
tolerate a compiler that checks things for us.

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

Re: code partitioning (was: Future with Ada)

[Kevin Cline]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<DPweFozQbILl@eisner.encompasserve.org>...
> In article <mailman.1015999862.11331.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.com> writes:
> >> From: Wes Groleau <wesgroleau@despammed.com>
> >>    case Animal is
>       snip
> >>    end case (Animal);   -- yet another way of
> >>                         -- naming a case statement
> > 
> > Nonono
> > 
> > case [expression] is
> >   ...
> > end case;
> > 
> > So how about
> > 
> > case Some*weird*and/long+expression is
> >   ...
> > end case Some*weird*and/long+expression;
> 
> I prefer:
> 
> 	case Some*weird*and/long+expression is
> 	  ...
> 	end case;	-- Some*weird*and/long+expression
> 
> since it requires no vendor action and I have resigned myself to
> the fact that successful programming can never be entirely devoid
> of self-discipline.
> 
> I have found that so long as _every_ end case has such a comment,
> I am unlikely to get them interchanged.

I prefer

    meaningful_name := some * weird * and / long + expression;
    case meaningful_name is
    end case; -- meaningful_name

Introducing local variables can improve readability.

Re: code partitioning (was: Future with Ada)

[Pascal Obry]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> I have found that so long as _every_ end case has such a comment,
> I am unlikely to get them interchanged.

"You have found" and "your are unlikely"... what about a project with 20 or
more developpers ? I really think that rules MUST be checked otherwise they
will be violated at some point... speaking from experiences :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: code partitioning (was: Future with Ada)

[Christoph Grein]

> I prefer
> 
>     meaningful_name := some * weird * and / long + expression;
>     case meaningful_name is
>     end case; -- meaningful_name
> 
> Introducing local variables can improve readability.

This is not the point. Of course this is sensible. My proper point against this proposal is:

Since a case statement has an expression syntactically, the expression would 
have to be repeated at the end

case expression is
  ..
end case expression;

and this is against the spirit of repeating only a short identifier (the 
defining_designator etc.) at the end.

Thus the proper way would be a {case_}statement_identifier:

[{case_}statement_identifier:]
case expression is
  ...
end case [{case_}identifier];

[The curly braces stand here for what is printed in italics in the RM.]

This is the only form I would like to see as a future syntax enhancement. We 
already have this for loops and blocks, so why not for ifs and cases (and 
selects).

We do not need weird new syntax rules.

Re: code partitioning (was: Future with Ada)

[John R. Strohm]

Well, yes, in theory that is all true.

In practice, in thirty years of slinging bits, both as student and as
professional, I have seen exactly one procedure that NEEDED to be more than
one printer page of code and that COULDN'T easily be factored down any
further.  (For the record, it was the photon torpedo routine in the old
Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a6lfgd$gj6$1@nh.pace.co.uk...
> Well, yea, I could see that - even breaking it up into a "when mammal ...
> when others..." case in something like this. It kind of goes to my
original
> point: You ought to keep ifs and cases short and as unnested as may make
> sense for the problem at hand, but don't go crazy.
>
> You've got to use some judgment, thinking "Shortness and non-nestedness
are
> good things taken from The Book Of Devoutly To Be Desired Results, but
lets
> not forget that the spirit of the law is to make things readable and
> comprehensible" If statements nest for three or four levels or span
several
> dozen lines, yet remain comprehensible (being a natural reflection of the
> problem at hand) and breaking them up would require unnatural acts of
> contortion, then don't fight it. Programming is often an "art" that
requires
> an "artistic eye" rather than an exact science... much like other writing
> and communication skills.
>
> 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:3C8E3110.F36F2DC8@despammed.com...
> >
> > Without actually endorsing this, here's a sort of
> > borderline situation:
> >
> >    case Animal is
> >
> >       when Horse | Tiger   | Elephant | Whale | Mouse |
> >            Dog   | Gorilla | Platypus | Koala | Dingo   =>
> >
> >          Classify_Mammal (Animal);
> >
> >       when Lizard | Snake | Alligator | Tortoise =>
> >
> >          Classify_Reptile (Animal);
> >
> >       ......
> >
> >       when others =>
> >
> >          Classify_Some_Really_Wierd_Thing (Animal);
> >
> >                         -- gratuitous demo of
> >    end case (Animal);   -- yet another way of
> >                         -- naming a case statement
> >
> >   -- to bring it back to the original topic
> >   -- now that I've updated the subject line  :-)
> >
>
>
>

Re: code partitioning (was: Future with Ada)

[Ted Dennison]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> In practice, in thirty years of slinging bits, both as student and as
> professional, I have seen exactly one procedure that NEEDED to be more than
> one printer page of code and that COULDN'T easily be factored down any
> further.  (For the record, it was the photon torpedo routine in the old
> Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)

I once had a command decoding and dispatching routine that had a >50
branch case statement. Not only was it really big, but it completly
blew by our MacCabe complexity target (somewhere around 4 or 5 I
belive). There was no cleaning that baby up.

But you are right that this is a rare exception.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: code partitioning (was: Future with Ada)

[Kevin Cline]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0203150615.4282773b@posting.google.com>...
> "John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> > In practice, in thirty years of slinging bits, both as student and as
> > professional, I have seen exactly one procedure that NEEDED to be more than
> > one printer page of code and that COULDN'T easily be factored down any
> > further.  (For the record, it was the photon torpedo routine in the old
> > Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)
> 
> I once had a command decoding and dispatching routine that had a >50
> branch case statement. Not only was it really big, but it completly
> blew by our MacCabe complexity target (somewhere around 4 or 5 I
> belive). There was no cleaning that baby up.

I have done this a few times in different ways:

* Use yacc or a similar tool to generate the code.  I did this when
I wrote an Ada program to parse Ada-83 package specifications.

* Convert the code to data.  During initialization,
create a tree with nodes labeled by commands and subcommands, 
with functions at the leaves.

* Embed the Tcl interpreter into the application.
This gives the users a lot scripting functionality for free.

Re: code partitioning (was: Future with Ada)

[Jacob Sparre Andersen]

Christoph Grein wrote:

> Thus the proper way would be a {case_}statement_identifier:
> 
> [{case_}statement_identifier:]
> case expression is
>   ...
> end case [{case_}identifier];

Agreed. And this would actually be a nice way to clarify
code a bit. On the other hand, should if statements also
have this possibility?

I would like to be allowed to include the name of the
defined record type after "end record".  I am aware that
record definitions, unlike case statements can not be
nested, so this is not nearly as important.

> We do not need weird new syntax rules.

Generally not.

Jacob
-- 
"The current state of knowledge can be summarised thus:
 In the beginning, there was nothing, which exploded."

Re: code partitioning (was: Future with Ada)

[Nick Williams]

Well, the reason for having labels on loops is fairly clear; to allow an
exit statement to exit from a loop other than the innermost enclosing one.
So there's obviously a concrete 'why' for loops - its not as clear for
blocks (although I can see that it might be nice to have a construct which
allows a new declarative region to be nameable).

On the other hand, allowing this for if and case statements sounds a lot
more like simple syntactic sugar. I don't really think it's sufficient to
say 'language construct A has this additional syntax; so why not B?', rather
the question should be 'why does language construct A have this additional
syntax, and does language construct B benefit from it in a consistent way?'.

Cheers,

Nick.

"Christoph Grein" <christoph.grein@eurocopter.com> wrote in message
news:mailman.1016084642.17231.comp.lang.ada@ada.eu.org...

> This is the only form I would like to see as a future syntax enhancement.
We
> already have this for loops and blocks, so why not for ifs and cases (and
> selects).
>
> We do not need weird new syntax rules.
>

Re: code partitioning (was: Future with Ada)

[Robert A Duff]

"Nick Williams" <nickw@acm.org> writes:

> Well, the reason for having labels on loops is fairly clear; to allow an
> exit statement to exit from a loop other than the innermost enclosing one.
> So there's obviously a concrete 'why' for loops - its not as clear for
> blocks (although I can see that it might be nice to have a construct which
> allows a new declarative region to be nameable).

I think the reason blocks can have names is so you can use them in
expanded names -- eg Block_Name.Object_In_Block.  Hardly essential, but
it seems like a nice property.  I think the 1983 RM has a note pointing
out that if you name all your blocks, you can always refer to anything
via a full expanded name (assuming Standard is not hidden).  This
implies that JDI thought this was a nice property for the language to
have.

I never put a name on a loop, unless there is an exit that refers to
that name.  And such an exit is always nested inside another loop.
That is, the existence of the name lets the reader know that something
unusual is going on (an exit from a more-nested loop) -- assuming the
reader knows I'm using this style, of course.

The visibility rules for these things are weird, especially if you
compare them to loop parameters.  The compiler has to jump through some
annoying hoops.  For example:

    procedure P is
    begin
        for X in 1..10 loop

            X: -- Illegal; loop name X is not visible here.
		while ... loop
		    null;
		end loop X;
        end loop;
    end P;

- Bob