Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Yannick Duchêne (Hibou57) on 6 Jun 2010 04:25 Le Sun, 06 Jun 2010 09:46:28 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > = exponentially > > http://en.wikipedia.org/wiki/Geometric_progression OK, a quasi-synonym >> I remember in the past (past year I think), we talked around generics >> hierarchy and generic packages as formal parameters. You had warned >> about >> possible complexity explosion in this area: is this about the same ? > > Yep. Once generic always generic. Two generics make four instantiations. > And the mill starts milling... This path is not the only one way. There can be instantiations to be used as basic components. Generics does not provide just a way to declare things, this also gives a way to implement, and implementation is an hidden thing (or else private at least). Generic origin of a type can be hidden (as an example) ; while obviously, some relationships are then lost. This can lead into an combinatorial explosion, right ; except âcanâ is not âalwaysâ (while I agree to say it can comes faster than supposed, and recurrence/recursivity should be in mind here while designing). -- 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 05:22 On Sun, 06 Jun 2010 10:25:11 +0200, Yannick Duchêne (Hibou57) wrote: > Le Sun, 06 Jun 2010 09:46:28 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a écrit: >> = exponentially >> >> http://en.wikipedia.org/wiki/Geometric_progression > OK, a quasi-synonym And, maybe, you have a chance of having it not geometric, but combinatorial... (:-)) http://en.wikipedia.org/wiki/Combinatorial_explosion >>> I remember in the past (past year I think), we talked around generics >>> hierarchy and generic packages as formal parameters. You had warned >>> about >>> possible complexity explosion in this area: is this about the same ? >> >> Yep. Once generic always generic. Two generics make four instantiations. >> And the mill starts milling... > This path is not the only one way. There can be instantiations to be used > as basic components. Generics does not provide just a way to declare > things, this also gives a way to implement, and implementation is an > hidden thing (or else private at least). Generic origin of a type can be > hidden (as an example) ; while obviously, some relationships are then lost. > > This can lead into an combinatorial explosion, right ; except “can” is not > “always” (while I agree to say it can comes faster than supposed, and > recurrence/recursivity should be in mind here while designing). Normally you wanted to postpone instantiation to as late as possible. But any delayed instantiation means a generic formal parameter in another generics and so it leads to the explosion at the point where you ultimately instantiate the mess. This is not a problem for small projects. That is why most Ada people don't see generics as a problem. 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... But if you force yourself to instantiate earlier, you get a very fragile design. Generics are against good design. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Simon Wright on 6 Jun 2010 06:22 "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!) Because you have given your word in the past and it has proved trustworthy? Because you are a member of a professional organisation (eg, chartered engineer)? Because you've been following appropriate review processes?
From: Yannick Duchêne (Hibou57) on 6 Jun 2010 07:06 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 ? > design. Generics are against good design. Suppose that is true, then this suggest to choose to use generic is a bad design choice. An example objection could be, when a generic is used, other ways may have been evaluated and excluded for some reasons. 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 ? (George would be interested in this I suppose) 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. Your comments suggest this interesting question about what could be alternatives to generics. > 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. So some assertions can be made on the validity of a generic's logic and implementation. 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. -- 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 07:18
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? > 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. > Because you are a member of a professional organisation (eg, chartered > engineer)? Substitutes words of other people for mine. (And be sure, they use mine in support of theirs! (:-)) > Because you've been following appropriate review processes? Made by other members of the clique, by state bureaucrats? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |