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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.238.65 with SMTP id vi1mr6072858pbc.7.1341080769747; Sat, 30 Jun 2012 11:26:09 -0700 (PDT) Path: l9ni3166pbj.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sat, 30 Jun 2012 21:26:09 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> Mime-Version: 1.0 X-Trace: individual.net 1LCGX89iiZxjlOalmR5MKg2zMr8epGkCQRlJobCaDcfmfSj2iw2Hqdc695QMaF7VNb Cancel-Lock: sha1:yzcpwwihZPyT00acS/r+VeCxCn8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-06-30T21:26:09+03:00 List-Id: On 12-06-30 20:37 , Brian Drummond wrote: > On Sat, 30 Jun 2012 11:51:51 -0400, Robert A Duff wrote: > >> Brian Drummond writes: >> >>> We can overload existing operators (+,-,etc) > ... >>> But we can't define new ones, e.g. // to denote the value of electronic >>> components connected in a parallel circuit) >>> One obvious problem with an extensible set of operators, in an operator >>> precedence grammar, is assigning the precedence level of new operators. ... >>> Given that ways can be found to assign precedence to new operators, why >>> are extensible operators not found in more languages that allow >>> overloading? >> >> Perhaps because dealing with precedence adds complexity. >> What happens if package P1 declares that "//" has higher precedence than >> "\\\", and P2 declares the opposite, >> and you say "with P1, P2;"? The obvious answer is that they then have >> unrelated precedence within the scope of that "with". But it definitely >> adds complexity. > > Conflicting precedences are a problem I hadn't considered. There seems to > be some parallel with the diamond problem in multiple inheritance. > If P1."//" and P2."//" apply to different types, does it really matter > that they have different precedences, unless the base type is the same? > Possibly yes, from the perspective that the expression parser now has to > take the operand types as well as the operator symbol into consideration. Overload resolution would be very messed up. The parsed structure of the expression would be different for different resolutions of overloaded names and operators. Ugh! IMO the new operators should all be put at the same precedence level, either above or below all the predefined operators. Perhaps below (most loosely binding) is the better choice. So a + b // c * d would be parsed as (a+b) // (c*d). The parentheses around the operands could even be required. New unary operators should also be allowed, of course. > Agree that it could be over-used. But in some domains it would be useful. > After all, I doubt you would want to see too much > "Add(A,Multiply(B,C))"... I agree that defining new operators could be useful. It could also be overused to make programs hard to read and understand, for a reader who does not already know what the new operators mean. But I don't think we should forbid new language features just because they can be misused. After all, the language cannot require that function names should make sense -- if they don't, nested function applications can be hard to understand, too. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .