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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-18 16:55:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!msunews!not-for-mail From: "Chad R. Meiners" Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X "left hand side" repeater. Date: Wed, 18 Jun 2003 19:50:27 -0400 Organization: Michigan State University Message-ID: References: <3EECA772.4B662024@adaworks.com> NNTP-Posting-Host: arctic.cse.msu.edu X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: archiver1.google.com comp.lang.ada:39419 Date: 2003-06-18T19:50:27-04:00 List-Id: "John R. Strohm" wrote in message news:bcqp5o$coi@library2.airnews.net... > > Maybe I'm just weird, but I happen to think that > declare > Pixel : Buffer_Element renames Screen.Buffer(i); > begin > Pixel := > To_Red(Get_Green(Pixel)) + > To_Green(Get_Blue(Pixel)) + > To_Blue(Get_Red(Pixel)); > end; > is about right. I would definitely agree given that more than one variable needs to be declared, exception handling is needed or more than one assignment needs to be made. However for one 'rename' with one assignment statement, I have always found a block statement annoying. > Further, more to the point, your concept > is in > is unbracketed. This is explicitly contrary to Ada practice. Actually the concept is more like is in > Ada has EVERYWHERE ELSE eschewed single-statement scope limits, preferring > explicitly-bracketed scope instead. Scope is ended by the semicolon like many other constructs in Ada. >In C, one writes Irrelevant, the form explicitly forbids multiple statements hence the is in ^ an assignment statment NOT a statement > One would expect that any such construct as yours should use explicit > bracketing, rather than implicitly bracket to one statement. There is no bracketing. The id is only for the single statement by form. > Now consider: > > declare > Pixel : Buffer_Element renames Screen.Buffer(i); > begin > Pixel.Color := > To_Red(Get_Green(Pixel.Color)) + > To_Green(Get_Blue(Pixel.Color)) + > To_Blue(Get_Red(Pixel.Color)); > Pixel.Highlight := 255 - Pixel.Highlight; > end; Related multiple statements do deserve a block. > vs. your > > Pixel is Screen.Buffer(i) in > Pixel.Color := > To_Red(Get_Green(Pixel.Color)) + > To_Green(Get_Blue(Pixel.Color)) + > To_Blue(Get_Red(Pixel.Color)); > > Pixel is Screen.Buffer(i) in > Pixel.Highlight := 255 - Pixel.Highlight; First let us fix the example Color is Screen.Buffer(i).Color in Color := To_Red(Get_Green(Color)) + To_Green(Get_Blue(Color)) + To_Blue(Get_Red(Color)); Highlight is Screen.Buffer(i).Highlight in Highlight := 255 - Highlight; or Pixel is Screen.Buffer(i) in Pixel := (Color => To_Red(Get_Green(Pixel.Color)) + To_Green(Get_Blue(Pixel.Color)) + To_Blue(Get_Red(Pixel.Color)), Highlight => 255 - Pixel.Highlight ); The idea was to simplify certain assignment statements; the syntax should not be used as a replacement of blocks. It does not make sense to use multiple renamed assignment statement for the same variable name. The block statement will win out in that case. I was suggesting an alternative syntax for the Var := {} + 1; suggestion in the hopes that if someone wanted to suggest such an addition to the language that it would encourage a readable syntax in that suggestion.