From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92c39a3be0a7f17d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-14 04:47:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!freenix!enst!enst.fr!not-for-mail From: Michal Nowak Newsgroups: comp.lang.ada Subject: Re: labeling (was: partitioning (was: Future)) Date: Thu, 14 Mar 2002 13:46:16 +0100 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: References: <3C7B0B13.3080003@worldnet.att.net> <3C7D1C89.2000803@home.com> <3C7E7CAD.7070504@mail.com> <3C7FB9D2.D9C6E055@boeing.com> <3C81DF1F.9000503@mail.com> <3C83A112.6080302@mail.com> <3C84223C.A356F466@adaworks.com> <3C853A04.34826F39@despammed.com> <3C8D0D70.BB09F3DA@despammed.com> <3C8E3110.F36F2DC8@despammed.com> <3C8F575D.61EE90A9@despammed.com> Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT X-Trace: avanie.enst.fr 1016110022 18926 137.194.161.2 (14 Mar 2002 12:47:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Thu, 14 Mar 2002 12:47:02 +0000 (UTC) Return-Path: In-reply-to: <3C8F575D.61EE90A9@despammed.com> X-Mailer: Calypso Version 3.20.01.01 (3) Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.8 Precedence: bulk X-Reply-To: vinnie@inetia.pl List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:21218 Date: 2002-03-14T13:46:16+01:00 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