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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,32d9aa9d79729b31 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.67 with SMTP id ry3mr14173476pbc.8.1340745283364; Tue, 26 Jun 2012 14:14:43 -0700 (PDT) Path: l9ni23297pbj.0!nntp.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Any easy/build-in construct to extract submatrices from larger matrix? Date: Tue, 26 Jun 2012 17:14:42 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <788af57d-750d-418d-94bb-75c6557e36a9@g4g2000pbn.googlegroups.com> <5d23a78c-4bf2-4d07-8bca-8fac2064d5af@googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1340745282 12547 192.74.137.71 (26 Jun 2012 21:14:42 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 26 Jun 2012 21:14:42 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:oiqzx6pTM7WzTZ8S0VHL8JW6JnM= Content-Type: text/plain; charset=us-ascii Date: 2012-06-26T17:14:42-04:00 List-Id: Adam Beneschan writes: > In Ada 83, those three characters could be replaced by %, !, : > respectively. (It's still in the language as a deprecated feature; > see J.2.) > > I don't think it would have worked to say that [] is used for array > indexing, but that they could be replaced by () if the symbols [] > weren't available. The reason was is that changing [] to () would > introduce some ambiguities where none existed before, which I think > would really screw up the overload resolution rules. (Suppose you > have two functions F, one that takes an integer parameter and returns > an integer, and one that takes no parameters and returns a array of > integer or an access to an array of integer. Now, if [] were used as > the array index, with no replacement allowed? F(3) would > unambiguously call the F that takes a parameter and F[3] would > unambiguously call the parameterless F that returns an array or > access-array. But what if the rules said that [ and ] could be > relaced by ( and )? What would the rules say about F(3) now? You could make that work. The rules would say that F(3) and F[3] are ambiguous, given the two F's you mention above. Then a legality rule would say you have to use [] for arrays. But that's not what I was thinking of. >...I think > this would be too confusing.) Agreed. And it doesn't really accomplish the goal, because when you see A(I) you don't know if it's a call or an array indexing. Apparently, Ichbiah et al didn't share that goal anyway -- they thought it's a feature to confuse calls and array indexing. I have mixed feelings about it. On the one hand, a constant array is just like a function without side effects. But on the other hand, when you consider that you can do "A(I) := ..." for arrays, and function calls can go around modifying global variables, the two features don't look very similar. All in all, I'm in favor of two different notations. >...Another possibility would be to say > that [ and ] could be replaced by two-character sequences such as, for > instance, (: and :) This would be unambiguous because smileys hadn't > yet been invented. Yeah, THAT's what I was thinking of. Or (. and .) . >...I think that would have worked but I guess nobody > thought of that. Well, they should have. After all, they came up with essentially the same idea for " | #. And they supposedly started their design based on Pascal, which uses the same idea -- comments are surrounded by {...}, but you're allowed to use (*...*) instead. This isn't rocket science! ;-) Using the same syntax for arrays and functions doesn't bother me THAT much, but it really rubs me the wrong way that you can't have zero- and one-component positional aggregates. Using [...] for aggregates would solve that, without ambiguity. And blaming that large language design flaw on character set / keyboard issues doesn't hold water. The steelman requirement that somebody quoted was: "Every source program shall also have a representation that uses only the following 55 character subset of the ASCII graphics: Note "also have", which can be accomplished by these optional replacements. By they way, they didn't actually meet that requirement. Can you think of an Ada 83 program that cannot be represented in those 55 characters? ;-) - Bob