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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6609c40f81b32989 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!feeds.phibee-telecom.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!usenet-fr.net!nospam.fr.eu.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Why is Ada considered "too specialized" for scientific use Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <602abc7e-afbe-4862-8885-b349ac4e6b90@r1g2000yqb.googlegroups.com> <0361da85-c24e-464d-a409-a370978638bc@b33g2000yqc.googlegroups.com> <7276a247-2ad8-418e-b401-34a5d61c4166@g10g2000yqh.googlegroups.com> <1x71227mbo6z9$.12n4lsrnrdcyl.dlg@40tude.net> <98d79ce5-e45a-48c1-8979-1d0d1c12404c@i25g2000yqm.googlegroups.com> Date: Thu, 8 Apr 2010 13:53:53 +0200 Message-ID: <1rmpwk7jojhr3$.6dtrrt2anpqg.dlg@40tude.net> NNTP-Posting-Date: 08 Apr 2010 13:53:55 CEST NNTP-Posting-Host: 36f28861.newsspool3.arcor-online.net X-Trace: DXC=80ZnJ?]o5\iFXUDVUnEXQmMcF=Q^Z^V3h4Fo<]lROoRa8kF On Wed, 7 Apr 2010 13:21:22 -0700 (PDT), Maciej Sobczak wrote: > On 7 Kwi, 15:44, "Dmitry A. Kazakov" > wrote: > >>> As I've pointed out, that would be resolved in the same way as >>> overloading by return type. >> >> It must be a type different from My_Other_Magic_Type then. But the reader >> sees: >> >> � � Y : My_Other_Magic_Type; >> >> so what is the type of Y? If it effectively is not the type declared, then >> this does not look like a good idea. > > This is true and this is a result of the lack of parens. If Ada > adopted the convention of empty parens for parameterless functions, > then Y and Y () would not be as confusing. What is wrong with +Y or abs Y? If you have a operator ("+", "abs" or "()") applied to an object then it is visually a different case. >>>>> � �B := Y (3); -- function call on Y with one param >> >>>> Better it be ":="(B, "index" (Y, 3)); >> >>> Except that the notion of "index" might not be appropriate. Function >>> is a more general term (indexing is a kind of function, but not the >>> other way round). >> >> They do not intersect. Function has the syntax f(x,y,z). Index has the >> syntax x(y,z). > > You are not consistent. Index has the syntax x(y,z), which is > interchangeable with "index"(x,y,z). Function has the syntax f(x,y,z), > which might be an overloaded operator with syntax x(y,z). This makes > them overlapping. I think you are conflating syntax and semantics. Syntactically function call is not an operator and neither is indexing. Semantically all three are just subprograms. >>> Except that with the overloaded function call operator, you would not >>> need "touch", as the function body would be already a right place to >>> put all such tracing. >> >> That depends on how you define the function "Y". > > "Y" is not a function, it is an object. > However, it can be used in the context where a different type is > expected that can be delivered by: > > function "call" (This : My_Other_Magic_Type) return T; > > where "call" is a new special operator name that I just invented. OK, I think there is a name for this: "implicit type conversion." Is it what you are proposing? IMO, arbitrary type conversions are unsafe. If I would introduce something alike I would simply use the interface inheritance, which Ada lacks so badly. E.g. type My_Other_Magic_Type is ... and interface T; -- T's interface is inherited ... private type My_Other_Magic_Type is ...; function To_T (This : My_Other_Magic_Type) return T; for Y as T use To_T; Now Y implements the interface of T (i.e. is a member of T'Class), but has the representation independent on T. All operations of T are implemented by the composition of Convert with the corresponding operation of T (if not overridden, of course). For in/out operations you will also need a backward conversion: function From_T (This : T) return My_Other_Magic_Type; for Y as T use From_T; >> The latter is not "touch", the former is ambiguous: >> >> � �Foo (Y); -- Is it Foo(Y), Foo("Y"(Y)), Foo("Y"("Y"(Y)))? > > It is not ambiguous if Foo expects T and T /= My_Other_Magic_Type - in > that case this is basic overload resolution. I meant the case when the result is My_Other_Magic_Type. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de