* Re: labeling (was: partitioning (was: Future))
@ 2002-03-15 8:20 Christoph Grein
2002-03-15 11:59 ` ARG Urgent Problems (was: labeling) Larry Kilgallen
0 siblings, 1 reply; 18+ messages in thread
From: Christoph Grein @ 2002-03-15 8:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* ARG Urgent Problems (was: labeling)
2002-03-15 8:20 labeling (was: partitioning (was: Future)) Christoph Grein
@ 2002-03-15 11:59 ` Larry Kilgallen
2002-03-17 12:59 ` Tarjei T. Jensen
0 siblings, 1 reply; 18+ messages in thread
From: Larry Kilgallen @ 2002-03-15 11:59 UTC (permalink / raw)
In article <mailman.1016180522.31471.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.com> writes:
> The ARG really has enough urgent problems to solve, and I bey they are
> reluctant to handle any such weird proposals.
Out of curiosity, what are some of the "urgent problems" ?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ARG Urgent Problems (was: labeling)
2002-03-15 11:59 ` ARG Urgent Problems (was: labeling) Larry Kilgallen
@ 2002-03-17 12:59 ` Tarjei T. Jensen
2002-03-17 13:11 ` Nick Williams
0 siblings, 1 reply; 18+ messages in thread
From: Tarjei T. Jensen @ 2002-03-17 12:59 UTC (permalink / raw)
Larry Kilgallen wrote:
> Christoph Grein writes:
>
> > The ARG really has enough urgent problems to solve, and I bey they are
> > reluctant to handle any such weird proposals.
>
> Out of curiosity, what are some of the "urgent problems" ?
They could get us unsigned integers and not just the positive part of
integers. By unsigned I mean unsigned with runtime checking.
Quoting C unsigned as a reason for not having real unsigned is pretty bogus
because C integers seems to wrap very well.
We don't want to abandon runtime checks on integers just because C does not
do any checking.
greetings,
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ARG Urgent Problems (was: labeling)
2002-03-17 12:59 ` Tarjei T. Jensen
@ 2002-03-17 13:11 ` Nick Williams
2002-03-19 9:22 ` Tarjei T. Jensen
0 siblings, 1 reply; 18+ messages in thread
From: Nick Williams @ 2002-03-17 13:11 UTC (permalink / raw)
What exactly do you mean by 'unsigned integers and not just the positive
part of integers'?
If you want to model unsigned integers the same way that C models them, then
use modular types, surely?
Nick.
"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote in message
news:a7240i$rh416@news.kvaerner.com...
> Larry Kilgallen wrote:
> > Christoph Grein writes:
> >
> > > The ARG really has enough urgent problems to solve, and I bey they are
> > > reluctant to handle any such weird proposals.
> >
> > Out of curiosity, what are some of the "urgent problems" ?
>
> They could get us unsigned integers and not just the positive part of
> integers. By unsigned I mean unsigned with runtime checking.
>
> Quoting C unsigned as a reason for not having real unsigned is pretty
bogus
> because C integers seems to wrap very well.
>
> We don't want to abandon runtime checks on integers just because C does
not
> do any checking.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ARG Urgent Problems (was: labeling)
2002-03-17 13:11 ` Nick Williams
@ 2002-03-19 9:22 ` Tarjei T. Jensen
2002-03-19 12:21 ` Jean-Pierre Rosen
0 siblings, 1 reply; 18+ messages in thread
From: Tarjei T. Jensen @ 2002-03-19 9:22 UTC (permalink / raw)
"Nick Williams" <nickw@acm.org> wrote in message
news:1016370675.163940@ananke.eclipse.net.uk...
> What exactly do you mean by 'unsigned integers and not just the positive
> part of integers'?
Unsigned in Ada (Natural) is from 0 to integer'last which is the same as
system.max_int;
> If you want to model unsigned integers the same way that C models them,
then
> use modular types, surely?
I just said that this is not what I want. I want a real unsigned with
rangechecking and the lot - and not the abominable modular type workaround.
It really should be possible to map the C type size_t to an ada unsigned
type without having to botch the job by using a modular type.
C allows both integers and unsigned to wrap, but somehow those who decides
these things think that therefore Ada unsigned above integer'last must wrap
as well.
That logic beats me.
greetings,
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ARG Urgent Problems (was: labeling)
2002-03-19 9:22 ` Tarjei T. Jensen
@ 2002-03-19 12:21 ` Jean-Pierre Rosen
2002-03-19 14:38 ` Tarjei T. Jensen
0 siblings, 1 reply; 18+ messages in thread
From: Jean-Pierre Rosen @ 2002-03-19 12:21 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> a �crit dans le message news: a7700l$84f4@news.kvaerner.com...
> C allows both integers and unsigned to wrap, but somehow those who decides
> these things think that therefore Ada unsigned above integer'last must wrap
> as well.
>
Maybe it's just that you missed an important feature of Ada: don't use predefined types, specify your needs, then declare the
appropriate types. You want a 32 bits integer without wrapping semantics? Fine, just declare:
type My_Int is range 0..2**32-1;
Your point is that there is no *predefined* type for this; in other languages you must rely on predefined types because it is all
you have - not in Ada.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ARG Urgent Problems (was: labeling)
2002-03-19 12:21 ` Jean-Pierre Rosen
@ 2002-03-19 14:38 ` Tarjei T. Jensen
0 siblings, 0 replies; 18+ messages in thread
From: Tarjei T. Jensen @ 2002-03-19 14:38 UTC (permalink / raw)
"Jean-Pierre Rosen" wrote
>
> "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> a �crit dans le message
news: a7700l$84f4@news.kvaerner.com...
> > C allows both integers and unsigned to wrap, but somehow those who
decides
> > these things think that therefore Ada unsigned above integer'last must
wrap
> > as well.
> >
> Maybe it's just that you missed an important feature of Ada: don't use
predefined types, specify your needs, then declare the
> appropriate types. You want a 32 bits integer without wrapping semantics?
Fine, just declare:
>
> type My_Int is range 0..2**32-1;
Try
type My_int is range 0 .. 2**64-1;
Even on 32bit unix there are the occational 64bit unsigned integer these
days.
greetings,
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
@ 2002-03-18 5:59 Christoph Grein
2002-03-18 22:52 ` Wes Groleau
0 siblings, 1 reply; 18+ messages in thread
From: Christoph Grein @ 2002-03-18 5:59 UTC (permalink / raw)
> 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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
@ 2002-03-13 13:55 Christoph Grein
2002-03-13 17:50 ` Wes Groleau
2002-03-15 16:07 ` Richard Riehle
0 siblings, 2 replies; 18+ messages in thread
From: Christoph Grein @ 2002-03-13 13:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-13 13:55 Christoph Grein
@ 2002-03-13 17:50 ` Wes Groleau
2002-03-15 16:07 ` Richard Riehle
1 sibling, 0 replies; 18+ messages in thread
From: Wes Groleau @ 2002-03-13 17:50 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-13 13:55 Christoph Grein
2002-03-13 17:50 ` Wes Groleau
@ 2002-03-15 16:07 ` Richard Riehle
1 sibling, 0 replies; 18+ messages in thread
From: Richard Riehle @ 2002-03-15 16:07 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 18+ messages in thread
* Future with Ada
@ 2001-11-09 17:59 Michal Nowak
2002-02-26 4:12 ` Jim Rogers
0 siblings, 1 reply; 18+ messages in thread
From: Michal Nowak @ 2001-11-09 17:59 UTC (permalink / raw)
To: comp.lang.ada usegroup->mailing list gateway
Some month ago I discovered Ada and found it a greatest programming
language among the common programming laguages taught at universities
(Pascal, C++, Java and others). I started play with Ada a bit and
experienced all benfits of using Ada (everyone here knows what they
are, so no need to write it).
During reading some posts here and looking through some job services
I found that Ada is not so widely used as C++ or Java nowadays.
I serioulsy think about catching a job in Ada after I finish my studies
(I'm on last year now). If to work as a programmer I would like to
write in Ada. I looked through some job offers at Ada Information
Clearinghouse. I did not browsed all, because I'm on dial-up connection,
but lots of them required at least 1-2 experience. I haven't found any
company in my country (Poland) who may need an Ada prorammer (especially
inexperianced newbie), so I cannot gain experience here.
It comes time to write my M. Sc. diploma and I am on a crossroads now.
I may use Java or Ada for it. I talked with my leading promotor and
told him, that I will prefer to use Ada. After explaining him all benefits
from using Ada he agreed with me. Considering facts given above I came to
two scenarios:
1. Use Ada for my M.Sc. diploma. This will allow me to gain some additional
experience in Ada (I know it does not count, but it is better to use it here
than nowhere).
2. Use Java or C++ for my diploma and use Ada for self-needed programs or
for pleasure. I will get more Java C++ experience here which will allow
me to catch better job at least my country.
It will be not commercial project, by it will be not typical student project
also. Doing it well from the beginnig to the end will help me to gain
some experience.
Of course the better scenario for me is the first one. Here comes my final
questions. Is there a possibility for inexperienced Ada programmer to
find a job? I suspect that there is, but where or how to seek it? Is
there a possibility to find somewhere such offers (for example job
services, which allow browsing offers sorted by years of experience
required)?
Thank you for your time,
regards,
Mike
-----------------------------------------
____|
\%/ |~~\
O |
o>> Mike Nowak |
T |
/ > vinnie@inetia.pl |
http://www.geocities.com/vinnie14pl _|__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
@ 2002-02-26 4:12 ` Jim Rogers
2002-02-27 17:51 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 18+ messages in thread
From: Jim Rogers @ 2002-02-26 4:12 UTC (permalink / raw)
Michael Card wrote:
> I was wondering why it is perceived as undesirable to train new
> programmers in Ada? Certainly hiring an experienced S/W engineer who
> has only done C++ or Java, for example, would not require a significant
> additional investment to train them in Ada? If teh language really
> offers benefits, wouldn't those benefits more than offset the
> relatively small cost of buying 2-3 weeks of intense Ada training for
> the programmers?
I agree. I have found good C++ programmers to be trainable.
I watched one pick up the basics of Ada in about 2 weeks with the
help of "Ada as a Second Language". He was using the Aonix
compiler and wanted to use the latest Visual Studio for his IDE.
No problem. He simply customized Visual Studio and proceded to
happily program in Ada. He was amused to discover that the Aonix
compiler worked better with the Microsoft debugger than did
Visual C++. He found he was able to display more detailed information
about arrays when using Aonix.
Jim Rogers
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-02-26 4:12 ` Jim Rogers
@ 2002-02-27 17:51 ` Warren W. Gay VE3WWG
2002-02-28 17:45 ` Michal Nowak
0 siblings, 1 reply; 18+ messages in thread
From: Warren W. Gay VE3WWG @ 2002-02-27 17:51 UTC (permalink / raw)
Jim Rogers wrote:
> Michael Card wrote:
>> I was wondering why it is perceived as undesirable to train new
>> programmers in Ada? Certainly hiring an experienced S/W engineer who
>> has only done C++ or Java, for example, would not require a significant
>> additional investment to train them in Ada? If teh language really
>> offers benefits, wouldn't those benefits more than offset the
>> relatively small cost of buying 2-3 weeks of intense Ada training for
>> the programmers?
>
> I agree. I have found good C++ programmers to be trainable.
> I watched one pick up the basics of Ada in about 2 weeks with the
> help of "Ada as a Second Language". ...
While I can only speak about my own experience here (ie. learning
Ada95), I would suggest that picking up the language in about 2 weeks
is about right.. but...
I found it took a while longer before I could properly
design applications from scratch in Ada95. This is because the
entire framework is considerably different than C/C++ from a
number of viewpoints, most notably from a visibility point of
view, not to mention standard packages et. al.
Ada's package design, its restrictions on visibility etc., can
lead to a lot of head-scratching to a C/C++ designer.
In C/C++ I was always able to obtain pointers to something,
declare a new friend function, whatever. Ada requires you to
more carefully think about all these relationships before hand,
or you wind up moving/rewriting parts of your application
later as you get those "you can't get there from here" messages
from your favourite Ada compiler.
In this regard, I think somewhere between 3 months to a year
is required in order to gain the sufficient level of experience
to get it nearly right the first time. Even then, I believe
that the new Ada programmer still gets burned on what can
and cannot be done (in a given way) with generics for example.
The language is large enough that it takes time to gain enough
experience with all of these elements. For example, just the
"use" clause is hotly debated as to how and when
it should be used. I am still tinkering with how I want to
use "use", even though some advise against using it at all.
A new user of it is likely to abuse it, only to learn from
that lesson later on. ;-)
So while I agree that an experienced programmer can quickly
embrace Ada and *maintain* existing code, I do believe you
want someone with a bit more experience if he is designing
major subsystems from scratch. Otherwise, you'll have to
allow time for that programmer more time to learn from
his mistakes ;-)
Just my $0.02 worth.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-02-27 17:51 ` Warren W. Gay VE3WWG
@ 2002-02-28 17:45 ` Michal Nowak
2002-02-28 18:53 ` Hyman Rosen
0 siblings, 1 reply; 18+ messages in thread
From: Michal Nowak @ 2002-02-28 17:45 UTC (permalink / raw)
On 2002-02-27 at 17:51 Warren W. Gay VE3WWG wrote:
>While I can only speak about my own experience here (ie. learning
>Ada95), I would suggest that picking up the language in about 2 weeks
>is about right.. but...
>
>I found it took a while longer before I could properly
>design applications from scratch in Ada95. This is because the
>entire framework is considerably different than C/C++ from a
>number of viewpoints, most notably from a visibility point of
>view, not to mention standard packages et. al.
[cut the rest]
I fully agree with you. I had similiar experiences when I started
Ada (although to pick up the basics I had several hours - just one
lecture - which was in fact enough (but I really mean the basics)).
Paradoxically learning Ada came much easier to me than for example Java.
I think, that was because there is so much difference between Ada and C++.
This maybe similiar to comparing colours - it is harder to distinguish
white and yellow than white and blue (for example). Java has differrent
concept than C++, but uses C++ notation, what (I suppose) made me often
confused. It also caused, that I wrote C++ like code in Java, what rather
hasn't good effects ;-) (not to mention mixing C nad C++)
Another issue when learning a programming language is if the learner
likes it. Maybe that is why learning Ada came rather easily to me.
Even if language is hard to learn and somebody likes it, he will
learn it easily, he will not learn it properly, no matter how easy the
language is, if he dislikes it. Some of my university colleagues did
not wanted to learn another, a bit different language, that they already
knew. No matter how good features Ada has to offer, it seemed impossible
to convince them to learn Ada. "Ada is bad, I don't like it" - and that
was all I heard. In this cases, even if they had a whole year to spent, it
won't have any positive results.
Just my remarks,
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-02-28 17:45 ` Michal Nowak
@ 2002-02-28 18:53 ` Hyman Rosen
2002-03-01 17:26 ` Jeffrey Carter
0 siblings, 1 reply; 18+ messages in thread
From: Hyman Rosen @ 2002-02-28 18:53 UTC (permalink / raw)
Michal Nowak wrote:
> Another issue when learning a programming language is if the learner
> likes it. Maybe that is why learning Ada came rather easily to me.
I know I have a visceral dislike for the Pascal-style languages.
Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
way when I look at them. It's hard for me to appreciate that Ada
is intended to be reader-friendly when my brain is going "yuck"
whenever I look at some code.
Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
thing :-)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-02-28 18:53 ` Hyman Rosen
@ 2002-03-01 17:26 ` Jeffrey Carter
2002-03-03 8:26 ` Hyman Rosen
0 siblings, 1 reply; 18+ messages in thread
From: Jeffrey Carter @ 2002-03-01 17:26 UTC (permalink / raw)
Hyman Rosen wrote:
>
> I know I have a visceral dislike for the Pascal-style languages.
> Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
> way when I look at them. It's hard for me to appreciate that Ada
> is intended to be reader-friendly when my brain is going "yuck"
> whenever I look at some code.
>
> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> thing :-)
No, it's primarily the difference between coders and software engineers.
--
Jeffrey Carter
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-01 17:26 ` Jeffrey Carter
@ 2002-03-03 8:26 ` Hyman Rosen
2002-03-03 17:47 ` Chad R. Meiners
0 siblings, 1 reply; 18+ messages in thread
From: Hyman Rosen @ 2002-03-03 8:26 UTC (permalink / raw)
Jeffrey Carter wrote:
> No, it's primarily the difference between coders and software engineers.
You mean because software engineers value conciseness and economy
of expression, they prefer braces, while coders, who get paid by
the line, prefer the wordier languages and begin/end?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-03 8:26 ` Hyman Rosen
@ 2002-03-03 17:47 ` Chad R. Meiners
2002-03-04 16:30 ` Hyman Rosen
0 siblings, 1 reply; 18+ messages in thread
From: Chad R. Meiners @ 2002-03-03 17:47 UTC (permalink / raw)
Ah, there is that evil word, "concise". Often thought of as a holy
objective by computer scientist and mathematician alike. The danger here is
that people often equate conciseness with clarity. This of course is an
incorrect assumption. Concise expressions, theorems, definitions, etc are
valued since because they allow you to refresh your memory quickly. The
problem is that they do not make good teaching material without the
accompaniment of an introduction and explanation. The "curly braced
languages are concise hence better" argument is malformed at best and
perverse at worst since the mathematical symbols curly braced languages
adopted are meant for a completely different type of communication.
I know you most likely meant to include a smiley in your statement, Hyman,
but if you didn't perhaps the above will establish why many have preferences
opposite of yours.
-CRM
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C81DF1F.9000503@mail.com...
> Jeffrey Carter wrote:
> > No, it's primarily the difference between coders and software engineers.
>
> You mean because software engineers value conciseness and economy
> of expression, they prefer braces, while coders, who get paid by
> the line, prefer the wordier languages and begin/end?
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-03 17:47 ` Chad R. Meiners
@ 2002-03-04 16:30 ` Hyman Rosen
2002-03-05 1:41 ` Richard Riehle
0 siblings, 1 reply; 18+ messages in thread
From: Hyman Rosen @ 2002-03-04 16:30 UTC (permalink / raw)
Chad R. Meiners wrote:
> The problem is that they do not make good teaching material without the
> accompaniment of an introduction and explanation.
I find it difficult to believe that { } needs an introduction and
explanation that begin/end or if/end do not. On the other hand,
braces are light and airy and nicely set off and separate pieces
of program text which are more wordy, guiding the eye towards seeing
the structure of the code.
It's a religious issue, and a matter of taste. How many times, after
all, has this topic been discussed in the past?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-04 16:30 ` Hyman Rosen
@ 2002-03-05 1:41 ` Richard Riehle
2002-03-05 21:35 ` Wes Groleau
0 siblings, 1 reply; 18+ messages in thread
From: Richard Riehle @ 2002-03-05 1:41 UTC (permalink / raw)
Hyman Rosen wrote:
> Chad R. Meiners wrote:
> > The problem is that they do not make good teaching material without the
> > accompaniment of an introduction and explanation.
>
> I find it difficult to believe that { } needs an introduction and
> explanation that begin/end or if/end do not. On the other hand,
> braces are light and airy and nicely set off and separate pieces
> of program text which are more wordy, guiding the eye towards seeing
> the structure of the code.
>
> It's a religious issue, and a matter of taste. How many times, after
> all, has this topic been discussed in the past?
Actually, curly braces would not be so bad if the C/C++/Java compilers
were able to detect a name at the end of them. For example,
LabelName: {
source code
} LabelName
One reason I prefer Ada to the C family of languages is that the compiler
allows me to document my code blocks with names and actually checks
that the block I started corresponds to the name with which I ended it. Of
course, this is probably a religious issue and has very little to recommend
it
as a model for self-documenting code.
Richard Riehle
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-05 1:41 ` Richard Riehle
@ 2002-03-05 21:35 ` Wes Groleau
2002-03-05 22:04 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Wes Groleau @ 2002-03-05 21:35 UTC (permalink / raw)
> Actually, curly braces would not be so bad if the C/C++/Java compilers
> were able to detect a name at the end of them. ....
>
> One reason I prefer Ada to the C family of languages is that the compiler
> allows me to document my code blocks with names and actually checks
> that the block I started corresponds to the name with which I ended it. Of
> course, this is probably a religious issue and has very little to recommend
One minor thing I've always thought odd about Ada is the
inconsistency where some ends require a name, some
forbid it, and some don't care.
Also, some demand a keyword match (end record) and some don't.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-05 21:35 ` Wes Groleau
@ 2002-03-05 22:04 ` Marin David Condic
2002-03-06 16:36 ` Georg Bauhaus
0 siblings, 1 reply; 18+ messages in thread
From: Marin David Condic @ 2002-03-05 22:04 UTC (permalink / raw)
To toss in yet another stink-bomb... :-)
Why not allow the labeling of all structures that have an "end"? You can
name a loop with a label and it helps find which "end" you mean if you've
got nested loops. Same with declare blocks. Why not for "if" statements and
"case" statements? Maybe also records - but the record already has a name
and aren't nested so it would probably look inconsistent.
It probably wouldn't amount to a major syntax change & might be mildly
useful. But not having thought about it thoroughly, there may be issues.
(What would you do if you had lots of "elsif" parts?) Anyway, its just an
idea to think about....
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:3C853A04.34826F39@despammed.com...
>
> One minor thing I've always thought odd about Ada is the
> inconsistency where some ends require a name, some
> forbid it, and some don't care.
>
> Also, some demand a keyword match (end record) and some don't.
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-05 22:04 ` Marin David Condic
@ 2002-03-06 16:36 ` Georg Bauhaus
2002-03-06 17:27 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Georg Bauhaus @ 2002-03-06 16:36 UTC (permalink / raw)
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
:
: Why not for "if" statements
Hmm, are you suggesting that you feel comfortable with if
statements that span more than say 12 lines and/or are nested
to some unspeakable level of say 3 or more? :-)
- georg
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-06 16:36 ` Georg Bauhaus
@ 2002-03-06 17:27 ` Marin David Condic
2002-03-07 16:04 ` Georg Bauhaus
0 siblings, 1 reply; 18+ messages in thread
From: Marin David Condic @ 2002-03-06 17:27 UTC (permalink / raw)
"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a65gj5$n73$1@a1-hrz.uni-duisburg.de...
> Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> :
> : Why not for "if" statements
>
> Hmm, are you suggesting that you feel comfortable with if
> statements that span more than say 12 lines and/or are nested
> to some unspeakable level of say 3 or more? :-)
>
Why, "yes". What's your point? :-) Sometimes a big case or if is a perfectly
good way of reflecting what's going on. (Think of lots of "when" or "elsif"
parts, for example.) Things should be made as simple as possible, but no
simpler.
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/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-06 17:27 ` Marin David Condic
@ 2002-03-07 16:04 ` Georg Bauhaus
2002-03-07 16:42 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Georg Bauhaus @ 2002-03-07 16:04 UTC (permalink / raw)
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
: Sometimes a big case or if is a perfectly
: good way of reflecting what's going on. (Think of lots of "when" or "elsif"
: parts, for example.) Things should be made as simple as possible, but no
: simpler.
yes, sometimes, highest speed dfa in inner loops, say?.
my point was that this need not be reflected in "big" if, in a sense.
With inlined subprograms, tag magic, ... you can do a lot to reduce
the "textual length" of an if or case statement, without much or any
loss in performance. At the expense of increased expressiveness,
sometimes :-)
I'm saying this remembering a 500 lines program consisting of one
procedure, nested ifs and some state variables named state1 etc,
no comment, no layout, produced by a human.
Even at only 500 lines this wasn't exactely a pleasure, and it
turned out that the program worked by accident.
- georg
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-07 16:04 ` Georg Bauhaus
@ 2002-03-07 16:42 ` Marin David Condic
2002-03-11 20:02 ` Wes Groleau
0 siblings, 1 reply; 18+ messages in thread
From: Marin David Condic @ 2002-03-07 16:42 UTC (permalink / raw)
Oh... I probably wouldn't do it out of concern for speed. I'd do it if it
seemed that constructing subprograms to squeeze something into some
arbitrary line or nesting limit was going to make the code less intuitively
obvious to the casual observer. Say you have an enumeration with 20 values
and a case statement handling it with 10 statements per enumeral. That's 200
lines + overhead, right? Would you create something like:
case (var) is
when First_Enum =>
Do_Ten_Lines_Of_Stuff ; -- I wouldn't generally object to this...
maybe
when others =>
Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
end case ;
procedure Do_Another_Case_In_A_Procedure (var : in var_type) is
begin
case (var) is
when Second_Enum =>
Do_Ten_Lines_Of_Stuff ;
when others =>
Do_Yet_Another_Case_In_A_Procedure (var) ;
end case ;
end Do_Another_Case_In_A_Procedure ;
And so on, and so on, and so on... Just to avoid a 200 line case statement
where and "end case Identifier;" might help you see what you were ending? I
guess I've written enough code where I've exceeded a screen's worth of lines
or had two or three levels of nesting and thought it would be useful to
identify what the "end" parts came from. If that's bad code by some
definition of "bad" then I guess I'll just have to live with the stigma.
(Bad Programmer! No Cookie! :-)
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/
"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a6831k$3ls$1@a1-hrz.uni-duisburg.de...
>
> yes, sometimes, highest speed dfa in inner loops, say?.
> my point was that this need not be reflected in "big" if, in a sense.
> With inlined subprograms, tag magic, ... you can do a lot to reduce
> the "textual length" of an if or case statement, without much or any
> loss in performance. At the expense of increased expressiveness,
> sometimes :-)
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-07 16:42 ` Marin David Condic
@ 2002-03-11 20:02 ` Wes Groleau
2002-03-11 23:56 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Wes Groleau @ 2002-03-11 20:02 UTC (permalink / raw)
> when others =>
> Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
I would, too. But I would probably NOT object to
when others =>
Default_Var_Handling (voo);
Matter of fact, whether by nesting or by calling,
I would object to a case choice on a variable that
dispatches to a case on the same variable.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Future with Ada
2002-03-11 20:02 ` Wes Groleau
@ 2002-03-11 23:56 ` Marin David Condic
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
0 siblings, 1 reply; 18+ messages in thread
From: Marin David Condic @ 2002-03-11 23:56 UTC (permalink / raw)
I *think* we're on the same wavelength. I was trying to say I don't object
to something like:
case (Var) is
when Enum_01 =>
Something_01 ;
when Enum_02 =>
Something_02 ;
when Enum_03 =>
Something_03 ;
when Enum_04 =>
Something_04 ;
when Enum_05 =>
Something_05 ;
when Enum_06 =>
Something_06 ;
when Enum_etc =>
Something_etc ;
when others =>
Something_Others ;
end case ;
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
stupid-code-trick needed to bust up the case statement to make it shorter.
Can you think of a way to make a case statement like this shorter that
doesn't look silly? (Assuming you've got 20 or so enumerals for some
reason - op-codes maybe? Lexical elements of some language you're parsing?
Reserved words in Ada? Not hard to imagine a fairly long list of enumerals,
eh?)
Once that case statement gets longer than a screen, I'd find it handy to
have a name at the end of it reminding me of what I'm ending. Of course, one
could always encase the case in a procedure that did nothing more than
provide the name for the check - and I'd think that was a good thing. But
would you try to make that procedure into three procedures if the case was
75 lines long just to shorten it up into 25 line segments?
Maybe I've run into similar things with if statements or nesting of
structures and didn't want to start making subprograms that had no
identifiable function other than to encapsulate some arbitrary chunk of code
& avoid some arbitrary nesting or line length limit. If I can write a
subprogram name like: "Is_Device_Ready" or
"Check_Employee_Payroll_Deductions" then I'm more than fine about taking
that nested if or long stream of code and hiding it in there. If I have a
hard time writing a good name for it and start resorting to
"Run_Some_Long_Block_Of_Code_To_Avoid_The_Nesting_Police", then I know I'm
better off leaving it the way it was. :-) (It reminds me of stunts pulled to
get subroutines under some arbitrary line limit - divide the routine you
have by the number of lines in the arbitrary limit and just find convenient
places to cut along those breaks. One 400 line subroutine becomes four 100
line routines with a "main" to call each in sequence, eh? :-)
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:3C8D0D70.BB09F3DA@despammed.com...
>
> > when others =>
> > Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to
this.
>
> I would, too. But I would probably NOT object to
>
> when others =>
> Default_Var_Handling (voo);
>
> Matter of fact, whether by nesting or by calling,
> I would object to a case choice on a variable that
> dispatches to a case on the same variable.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-11 23:56 ` Marin David Condic
@ 2002-03-12 16:47 ` Wes Groleau
2002-03-12 17:56 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Wes Groleau @ 2002-03-12 16:47 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
@ 2002-03-12 17:56 ` Marin David Condic
2002-03-13 13:42 ` labeling (was: partitioning (was: Future)) Wes Groleau
0 siblings, 1 reply; 18+ messages in thread
From: Marin David Condic @ 2002-03-12 17:56 UTC (permalink / raw)
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 :-)
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-12 17:56 ` Marin David Condic
@ 2002-03-13 13:42 ` Wes Groleau
2002-03-14 12:46 ` Michal Nowak
2002-03-15 8:00 ` Tarjei T. Jensen
0 siblings, 2 replies; 18+ messages in thread
From: Wes Groleau @ 2002-03-13 13:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-13 13:42 ` labeling (was: partitioning (was: Future)) Wes Groleau
@ 2002-03-14 12:46 ` Michal Nowak
2002-03-14 17:27 ` Wes Groleau
2002-03-15 8:00 ` Tarjei T. Jensen
1 sibling, 1 reply; 18+ messages in thread
From: Michal Nowak @ 2002-03-14 12:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-14 12:46 ` Michal Nowak
@ 2002-03-14 17:27 ` Wes Groleau
2002-03-14 20:27 ` Marin David Condic
0 siblings, 1 reply; 18+ messages in thread
From: Wes Groleau @ 2002-03-14 17:27 UTC (permalink / raw)
> > 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-14 17:27 ` Wes Groleau
@ 2002-03-14 20:27 ` Marin David Condic
0 siblings, 0 replies; 18+ messages in thread
From: Marin David Condic @ 2002-03-14 20:27 UTC (permalink / raw)
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.)
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: labeling (was: partitioning (was: Future))
2002-03-13 13:42 ` labeling (was: partitioning (was: Future)) Wes Groleau
2002-03-14 12:46 ` Michal Nowak
@ 2002-03-15 8:00 ` Tarjei T. Jensen
2002-03-15 15:10 ` Wes Groleau
1 sibling, 1 reply; 18+ messages in thread
From: Tarjei T. Jensen @ 2002-03-15 8:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2002-03-19 14:38 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-15 8:20 labeling (was: partitioning (was: Future)) Christoph Grein
2002-03-15 11:59 ` ARG Urgent Problems (was: labeling) Larry Kilgallen
2002-03-17 12:59 ` Tarjei T. Jensen
2002-03-17 13:11 ` Nick Williams
2002-03-19 9:22 ` Tarjei T. Jensen
2002-03-19 12:21 ` Jean-Pierre Rosen
2002-03-19 14:38 ` Tarjei T. Jensen
-- strict thread matches above, loose matches on Subject: below --
2002-03-18 5:59 labeling (was: partitioning (was: Future)) Christoph Grein
2002-03-18 22:52 ` Wes Groleau
2002-03-13 13:55 Christoph Grein
2002-03-13 17:50 ` Wes Groleau
2002-03-15 16:07 ` Richard Riehle
2001-11-09 17:59 Future with Ada Michal Nowak
2002-02-26 4:12 ` Jim Rogers
2002-02-27 17:51 ` Warren W. Gay VE3WWG
2002-02-28 17:45 ` Michal Nowak
2002-02-28 18:53 ` Hyman Rosen
2002-03-01 17:26 ` Jeffrey Carter
2002-03-03 8:26 ` Hyman Rosen
2002-03-03 17:47 ` Chad R. Meiners
2002-03-04 16:30 ` Hyman Rosen
2002-03-05 1:41 ` Richard Riehle
2002-03-05 21:35 ` Wes Groleau
2002-03-05 22:04 ` Marin David Condic
2002-03-06 16:36 ` Georg Bauhaus
2002-03-06 17:27 ` Marin David Condic
2002-03-07 16:04 ` Georg Bauhaus
2002-03-07 16:42 ` Marin David Condic
2002-03-11 20:02 ` Wes Groleau
2002-03-11 23:56 ` Marin David Condic
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
2002-03-12 17:56 ` Marin David Condic
2002-03-13 13:42 ` labeling (was: partitioning (was: Future)) Wes Groleau
2002-03-14 12:46 ` Michal Nowak
2002-03-14 17:27 ` Wes Groleau
2002-03-14 20:27 ` Marin David Condic
2002-03-15 8:00 ` Tarjei T. Jensen
2002-03-15 15:10 ` Wes Groleau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox