Why is Ada considered "too specialized" for scientific use
in [ADA]
|
From: Dmitry A. Kazakov on 7 Apr 2010 04:24 On Wed, 7 Apr 2010 00:28:22 -0700 (PDT), Maciej Sobczak wrote: > On 6 Kwi, 10:07, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > >> It is only a pity that there would be no way to overload a function >> call operator for the parameterless case. ;-) > > Heck, when I think more about this it seems that even this would be > possible by analyzing the context of the given expression. That would > work in a similar way as overloading on return types. > For example, assuming that My_Magic_Type has an overloaded procedure > call operator and My_Other_Magic_Type has an overloaded function call > operator: > > declare > X : My_Magic_Type; > Y : My_Other_Magic_Type; > begin > X; -- parameterless procedure call on X A reader would expect this procedure idempotent. Consider a program: X; X; X; -- What does this do? > A := Y; -- parameterless function call on Y I would prefer the ":=" (A, Y); interpretation, here. > X (1, 2); -- procedure call on X with two params I played with the idea of adding procedural operators. E.g. X + 1; meaning a call to procedure "+" (X : in out Foo; Increment : Integer); > B := Y (3); -- function call on Y with one param Better it be ":="(B, "index" (Y, 3)); > end; > > But I'm not really sure if that would be actually useful in the > context of other Ada features. The things you could do with your proposal could probably be achieved in other ways. For example, I considered a "touch" primitive operation, which similarly to Adjust, to be called each time you access a volatile object in order to get its value. This could be useful for tracing, interlocking, garbage collection, persistency layer purposes, etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: MRE on 7 Apr 2010 05:17 On 6 Apr., 19:53, Sebastian Hanigk <sebastian.han...(a)fs.tum.de> wrote: > Warren <ve3...(a)gmail.com> writes: > > Obviously Fortran persists because of existing code base and > > those that only "know" that. But egads, the current rendition > > of Fortran seem to have so many "bags on the side" and is > > downright "butt ugly". Why anyone would want to continue > > to wallow in that swill, is beyond me. Ada as a language OTOH, > > is so nice and clean by comparison. > > I won't even start with your puny attempts at a language crusade, > suffice to say that all the niceness and cleanness is quite unusable if > you don't have a compiler. And on most supercomputers where serious > number crunching is performed, you do not have an Ada compiler and even > building gnat would be a very major pain (bootstrapping ...). > > Regards, > > Sebastian Depends on your cost-model. If your man-hours for writing the code don't count, go on with C or Fortran. If they are a factor, maybe it's worth to spend a couple of thousand for getting support from a compiler vendor to port GNAT. Thanks btw. for showing quite clearly, that it's not only the "Ada- Guys" who are rude. Marc
From: Maciej Sobczak on 7 Apr 2010 07:59 On 7 Kwi, 10:24, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > A reader would expect this procedure idempotent. Consider a program: > > X; X; X; -- What does this do? This is the same as today with regular parameterless procedures: procedure X (Spacing : in Positive_Count := 1) renames Ada.Text_IO.New_Line; Now, what the reader would expect from your example? > > A := Y; -- parameterless function call on Y > > I would prefer the ":=" (A, Y); interpretation, here. As I've pointed out, that would be resolved in the same way as overloading by return type. The ":=" (A, Y) interpretation might not match, whereas the overloaded function call on My_Other_Magic_Type might return the type that is appropriate for assignment to A. It's a regular overload resolution stuff. > > 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). > The things you could do with your proposal could probably be achieved in > other ways. For example, I considered a "touch" primitive operation, which > similarly to Adjust, to be called each time you access a volatile object in > order to get its value. This could be useful for tracing, interlocking, > garbage collection, persistency layer purposes, etc. 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. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 7 Apr 2010 09:44 On Wed, 7 Apr 2010 04:59:59 -0700 (PDT), Maciej Sobczak wrote: > On 7 Kwi, 10:24, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> A reader would expect this procedure idempotent. Consider a program: >> >> � �X; X; X; -- What does this do? > > This is the same as today with regular parameterless procedures: > > procedure X (Spacing : in Positive_Count := 1) > renames Ada.Text_IO.New_Line; > > Now, what the reader would expect from your example? The reader knows that New_Line is a shortcut for New_Line (Standard_Input); It is a bad style to hide the effects of a procedure. New_Line is rare exception form this rule. >>> � �A := Y; � � -- parameterless function call on Y >> >> I would prefer the ":=" (A, Y); interpretation, here. > > 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. >>> � �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). >> The things you could do with your proposal could probably be achieved in >> other ways. For example, I considered a "touch" primitive operation, which >> similarly to Adjust, to be called each time you access a volatile object in >> order to get its value. This could be useful for tracing, interlocking, >> garbage collection, persistency layer purposes, etc. > > 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". Is it function "Y" (This : My_Other_Magic_Type) return My_Other_Magic_Type; or function "Y" return My_Other_Magic_Type; The latter is not "touch", the former is ambiguous: Foo (Y); -- Is it Foo(Y), Foo("Y"(Y)), Foo("Y"("Y"(Y)))? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Randy Brukardt on 7 Apr 2010 16:07
"Nasser M. Abbasi" <nma(a)12000.org> wrote in message news:hpgs1t$eid$1(a)speranza.aioe.org... .... > Thanks for the link. Yes, I see this: > > "Essentially we are allowing a container to be "indexed" in the same way > as an array is indexed, with the key (or potentially various different key > types) being arbitrary. " > > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0139-2.txt?rev=1.5 > > This sounds good. Any guess when will gnat have this? 2012, 2013, 2014? Surely not until there is a firm proposal (all that exists now is an outline with no details). Beyond that, I doubt AdaCore will be announcing firm dates until its actually available. (They already have some 2012 stuff implemented, so it might not be a long wait.) Randy. |