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: Georg Bauhaus on 7 Jun 2010 11:50 On 07.06.10 17:09, Dmitry A. Kazakov wrote: > On Mon, 07 Jun 2010 17:00:07 +0200, Georg Bauhaus wrote: > >> On 07.06.10 16:51, Dmitry A. Kazakov wrote: >>> On Mon, 07 Jun 2010 16:12:38 +0200, Georg Bauhaus wrote: >>> >>>> On 07.06.10 14:22, Dmitry A. Kazakov wrote: >>> >>>>> This includes the exceptional ones. When bug >>>>> happens, the program is in no state. >>>> >>>> Erh, are you sure? >>> >>> Yes I am. Any program state is defined, it has some sematic interpretation >>> in the domain. Bug is when you have lost this synchronization. Meaningless >>> state is no state. >> >> Then what constitutes a bug? >> >> procedure add_to_account(Number: in out Account_ID; sum: Money) is >> client_account: Account := Find_Account(Number); >> begin >> -- FIXME: not ready, using dummy account >> client_account := Make_new_Account; >> end add_to_account; > > Where is a problem? The above program, if it enters production, has a bug, IMHO: if Passed_In > 0.0 then Lock.Seize; was := amount_in_account(123); add_to_account(123, sum => Passed_In); is := amount_in_account(123); Lock.Release; -- assume add_to_account is correct send(other_bank, is - was); Program state is meaningful, if buggy. Or are you defining a bug to be a state of the program to which you are unable to assign meaning?
From: Georg Bauhaus on 7 Jun 2010 12:25 On 07.06.10 17:34, Martin Krischik wrote: > Am 07.06.2010, 17:05 Uhr, schrieb Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de>: > >> And I certainly don't want *parts* of the >> program being turned off by compiler switches. > > In Java it is even worse: Parts of your program are switched on by > runtime switches. See the -enableassertions. -enableassertions, pragma Assertion_Policy, translation options like choice of exception handling mechanism, optimization, -gnato, they all effect a different program. They do so following language rules. What's so special about having an option for monitoring the program via assertions? Assertions work on boolean expressions. A can't think of a commandment obliging the programmer to force side effects into his/her boolean expressions. (And then selling the program without pointing out to the operators that assertion monitoring may lead to this and that effect.) Indeed, if you follow the rules of DbC, then assertion monitoring is *never* to touch the logic of your components. "Tampers with elements/cursors" in Ada.Containers isn't that different I think.
From: Georg Bauhaus on 7 Jun 2010 12:30 On 07.06.10 18:25, Georg Bauhaus wrote: > "Tampers with elements/cursors" in Ada.Containers > isn't that different I think. Meaning that if you want high speed children of Ada.Containers, you perform these checks in predicates inside Assert pragmas and turn them off once you have reason to trust your program.
From: Dmitry A. Kazakov on 7 Jun 2010 12:58 On Mon, 07 Jun 2010 17:50:25 +0200, Georg Bauhaus wrote: > On 07.06.10 17:09, Dmitry A. Kazakov wrote: >> On Mon, 07 Jun 2010 17:00:07 +0200, Georg Bauhaus wrote: >> >>> On 07.06.10 16:51, Dmitry A. Kazakov wrote: >>>> On Mon, 07 Jun 2010 16:12:38 +0200, Georg Bauhaus wrote: >>>> >>>>> On 07.06.10 14:22, Dmitry A. Kazakov wrote: >>>> >>>>>> This includes the exceptional ones. When bug >>>>>> happens, the program is in no state. >>>>> >>>>> Erh, are you sure? >>>> >>>> Yes I am. Any program state is defined, it has some sematic interpretation >>>> in the domain. Bug is when you have lost this synchronization. Meaningless >>>> state is no state. >>> >>> Then what constitutes a bug? >>> >>> procedure add_to_account(Number: in out Account_ID; sum: Money) is >>> client_account: Account := Find_Account(Number); >>> begin >>> -- FIXME: not ready, using dummy account >>> client_account := Make_new_Account; >>> end add_to_account; >> >> Where is a problem? > > The above program, if it enters production, has > a bug, IMHO: Yes, but it does not mean that the code has a bug. Stubs, mocks, emulators are *valid* programs. They have the contracts of their own, though related to the production contract. It is not a language issue, but of the unit test tool to prevent a stub to be linked in the production code. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 7 Jun 2010 13:09
On Mon, 07 Jun 2010 18:25:35 +0200, Georg Bauhaus wrote: > On 07.06.10 17:34, Martin Krischik wrote: >> Am 07.06.2010, 17:05 Uhr, schrieb Dmitry A. Kazakov >> <mailbox(a)dmitry-kazakov.de>: >> >>> And I certainly don't want *parts* of the >>> program being turned off by compiler switches. >> >> In Java it is even worse: Parts of your program are switched on by >> runtime switches. See the -enableassertions. > > -enableassertions, pragma Assertion_Policy, translation > options like choice of exception handling mechanism, > optimization, -gnato, they all effect a different program. > They do so following language rules. Which are designed to honor the principle "Don't touch the program semantics!" > What's so special > about having an option for monitoring the program > via assertions? That assertions do not obey the above principle => if that is the language rule, then that rule is a language design bug. Assertions are against good design, because Assertion_Error is a welcome excuse for a lazy programmer not to consider what shall be the consequences of the program entering an undesired state. He does not even to care to *name* this problem appropriately. It is just Assertion_Error. Even Oops : Exception; were better! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |