Ada noob here! Is Ada widely used?
in [ADA]
|
Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Dmitry A. Kazakov on 6 Jun 2010 07:45 On Sun, 06 Jun 2010 13:06:45 +0200, Yannick Duchêne (Hibou57) wrote: > Le Sun, 06 Jun 2010 11:22:07 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a écrit: >> But if you force yourself to instantiate earlier, you get a very fragile > Don't see a reason why ; and this even seems contradictory to me: the > earlier you instantiate, the less complex it is. Or not ? Less complex and more fragile, because of premature decisions to meet. The package Generic_Complex_Types requires the type Real to instantiate. You have to define this type, range, precision etc. Later on, if the choice might appear wrong, you will have a huge problem, if the instance is widely used. A typical solution is to pass the instance as a parameter of another generics. Welcome to the Hell... > An example objection could be, when a generic is used, > other ways may have been evaluated and excluded for some reasons. Right, just like gotos. > Or is > Ada missing something so that people don't have any other choice than > generic (generic as a fall-back) ? What could this other paradigm could > looks like then ? Dynamic polymorphism, abstract types, interface inheritance, constraining (discriminants), static functions. > In the area of other choices, would automatic generation or simply copy be > a better choice (as this is one of the cases generics avoid) ? I feel it > would be even less usable. Probably yes. Macro is a macro, even if you call it generics or template. >> Add here that generics are non-testable. You can test instances, you >> cannot generics. Then Ada has been drifting towards C++ in the sense >> what promises gives you a successful compilation of the generic >> body, little, very little, nothing... > (another matter this one) > This is not like if generics could be instantiated with anything. > Actually, this is not: you can require a formal parameter to be a discrete > type, to be derived from another type, etc. Yes. The language of generics regarding its formal parameters: C++: untyped Ada: typed, types are built-in, no abstract/user types whatsoever Must-be: ADT + OO .... too much work to invest into a meta language. Why not to concentrate on the object language, i.e. on the core Ada type system? > So some assertions can be made > on the validity of a generic's logic and implementation. Some, but as I said Ada drifts towards less checks. You can (and will) get errors upon instantiation even if actual parameters match the formals! > Perhaps you are > requesting for more ways to constrain formal parameters ? (I would agree > with you, unless SPARK already support generics, which I have still not > tested so far). > > Oops, I have implicitly replaced “testable” by “provable”, hope you don't > mind. I do. If you'd make them provable you would need not to test. The problem is that for generics provability is much harder than for the object language. The same question again. Why not to concentrate on the core Ada and integrate SPARK there? To me generics is a dead end. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on 6 Jun 2010 08:38 Le Sun, 06 Jun 2010 13:45:48 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > Less complex and more fragile, because of premature decisions to meet. > The > package Generic_Complex_Types requires the type Real to instantiate. You > have to define this type, range, precision etc. Later on, if the choice > might appear wrong, you will have a huge problem, if the instance is > widely > used. A typical solution is to pass the instance as a parameter of > another > generics. Welcome to the Hell... > Dynamic polymorphism, abstract types, interface inheritance, constraining > (discriminants), static functions. I guess for Complex you would like constraining discriminants. The funny part is that I actually see generics as a way to define ADT. > Probably yes. Macro is a macro, even if you call it generics or template. You can pass anything to macro. Generics are safer at least for this reason. > Yes. The language of generics regarding its formal parameters: OK. I understand what you have in mind. > I do. If you'd make them provable you would need not to test. The problem > is that for generics provability is much harder than for the object > language. The same question again. Why not to concentrate on the core Ada > and integrate SPARK there? Would be great! :-) (would have to make SPARK a bit more predictable by the way... I have some idea in the area of SPARK, but this would make it different than what it actually is, and I feel this would be a lonesome story) Finally we end up in this oooold story about Ada, the most famous Ada issue : right at the beginning, someones were already suggesting to focus on a more core language, to better focus on what is the most relevant. > Some, but as I said Ada drifts towards less checks. Really ? I don't feel so much and don't believe most interested parties will allow it. The introduction of DbC in the Ada 2012 language itself, even goes the opposite way. Isn't it ? -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Dmitry A. Kazakov on 6 Jun 2010 09:10 On Sun, 06 Jun 2010 14:38:21 +0200, Yannick Duch�ne (Hibou57) wrote: > I guess for Complex you would like constraining discriminants. I would rather like to see Complex an implementation of field. We need working interfaces instead of Java-like mess. > The funny part is that I actually see generics as a way to define ADT. A very poor way. >> Probably yes. Macro is a macro, even if you call it generics or template. > You can pass anything to macro. Generics are safer at least for this > reason. To put a hand grenade in your pocket, is safer than in the mouth... >> Some, but as I said Ada drifts towards less checks. > Really ? I don't feel so much and don't believe most interested parties > will allow it. > The introduction of DbC in the Ada 2012 language itself, even goes the > opposite way. Isn't it ? You forgot that run-time check is not a check to me. It is a language design bug. I am afraid I will like Ada 2012 even less than Ada 2005. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Simon Wright on 6 Jun 2010 09:58 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Sun, 06 Jun 2010 11:22:41 +0100, Simon Wright wrote: > >> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >> >>> 2. Your confidence describes you, it does not the program. It fact, it >>> is like - I give my word, it works. Fine, but why anybody should trust >>> my word? >> >> Because you are a gentleman? (sorry -- been re-watching Lost In Austen!) > > A measure of being gentleman? This was meant to be a joke, apologies. More-or-less in this sense: http://en.wikipedia.org/wiki/Gentleman#Gentleman_by_conduct >> Because you have given your word in the past and it has proved >> trustworthy? > > Proved how, means, measures? BTW, statistics isn't applicable here either. > Let you write the same program 100 times. What is the probability that you > won't make a mistake X? It is not a probability. The code deviation after > stripping factors of learning, tiredness, disgust, rebellion is null. 'proved' might not have been the right word. I meant, if you are the release manager for a project and receive an updated package from a developer, you'll have a degree of trust in the suitability of the update which depends on how reliable that developer has been in the past.
From: Fritz Wuehler on 6 Jun 2010 12:41
> > Yes, only in H/C. No American bank uses MUMPS. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Are you sure? I've heard differently from MUMPS folks. Pretty sure. There may be the odd ball out there but 99.9% run IBM z/OS or VSE. If they say otherwise let them name names. |