From: Yannick Duchêne (Hibou57) on
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
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
"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
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
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