Why is Ada considered "too specialized" for scientific use
in [ADA]
|
From: Maciej Sobczak on 7 Apr 2010 16:21 On 7 Kwi, 15:44, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> 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. > >>> 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. > > 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. > 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. -- Maciej Sobczak * http://www.inspirel.com
From: Ken Thomas on 8 Apr 2010 06:10 I have used Ada for scientific computation for 25 years. It got off to a bad start because of the high cost of entry. Compilers were £1000+ for one licence (remember dongles). However, the recent Ada standards (2005) are very attractive. It is possible to interface software from other languages (MPI, Metis, UMFPACK) and the tool from gnat g++ -c -fdump-ada-spec ... is quite exciting. The containers are also useful. I have used an instaniation of Ada.Containers.Ordered_Maps to contain sparse matrices. Some of the applications are finite element software for Maxwell's equations.
From: Dmitry A. Kazakov on 8 Apr 2010 07:53 On Wed, 7 Apr 2010 13:21:22 -0700 (PDT), Maciej Sobczak wrote: > On 7 Kwi, 15:44, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > 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
From: Warren on 8 Apr 2010 12:40 Ken Thomas expounded in news:3bf0eb74-306c-48c4-b5ab- 858d88b4079d(a)s9g2000yqa.googlegroups.com: > However, the recent Ada standards (2005) are very attractive. It is > possible to interface software from other languages (MPI, Metis, > UMFPACK) and the tool from gnat g++ -c -fdump-ada-spec ... is quite > exciting. The containers are also useful. I have used an instaniation > of Ada.Containers.Ordered_Maps to contain sparse matrices. Speaking of 2005, I wouldn't mind acquiring a book on the essential elements of the 2005 features in Ada, without trudging through dry RM type prose. However, it seems that these new books are quite pricey, even used. Normally I can find a suitable deal on abebooks.com, but have come up empty so far. There must be a digestable summary on the net somewhere. Resources? Warren
From: Alex Mentis on 8 Apr 2010 14:30
On Apr 5, 4:28 pm, Warren <ve3...(a)gmail.com> wrote: > Nasser M. Abbasi expounded innews:hpddc6$csh$1(a)speranza.aioe.org: <snip> > > > Given this below > > > function Element (Container : Vector; > > Index : Index_Type) > > return Element_Type; > > > Then to get the element at index 5, one needs to write something like > > Element(V,5). > > > Is there a way to redefine this so one need to only write V(5) ? > > You could use V.Element(5), but that doesn't really > shorten the notation. > > You could declare an internal function for that purpose, though > there are probably better solutions: > > procedure My_Proc(args...) is > > package P is new Ada.Containers.Vector(...); > V : P.Vector; > > Function XV(X : Index_Type) returns Element_Type is > begin > return V.Element(X); > end; > begin > ... := XV(5); > <snip> I guess you could also use a renames clause: package Vec is new Vectors (Index_Type => Positive, Element_Type => Integer); use Vec; function X_At (Container : Vector; Index : Positive) return Integer renames Vec.Element; but you lose the object.method notation: Put ( X_At (V, 5)); |