* I am not understanding user defined exceptions @ 2017-02-03 20:27 patrick 2017-02-03 21:08 ` Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: patrick @ 2017-02-03 20:27 UTC (permalink / raw) Hi Everyone I am not understanding user defined exceptions. This little program will ask the user for integer entry twice. If I type 1 at the first entry, things work as expected and the exception is handled. However if I type, 2 and then 1, an exception is not raised at the second text_io.get. If we type something like : if x = 1 then raise Foo_Error; end if ; will x not be tested for exceptions conditions automatically from that point onward? If so, why would it not raise an exception if the second text_io.get came back with 1 ? Sorry for what will very likely be a stupid question-Patrick with ada.integer_text_io ; with ada.text_io ; -- -- -- -- -- -- procedure test_exceptions is package text_io renames ada.text_io ; package int_text_io renames ada.integer_text_io ; Foo_Error : exception ; x : integer ; begin int_text_io.get(x) ; if x = 1 then raise Foo_Error; end if ; int_text_io.get(x) ; -- why does execution reach this point if x is 1 after user input if x = 1 then text_io.put_line("x is 1, why wasn't an exception triggered?") ; end if ; text_io.put_line("ended without exceptions") ; exception when Foo_Error => text_io.put("error handled") ; end test_exceptions; ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-03 20:27 I am not understanding user defined exceptions patrick @ 2017-02-03 21:08 ` Randy Brukardt 2017-02-03 22:41 ` patrick 2017-02-04 1:26 ` Dennis Lee Bieber 2017-02-04 8:41 ` Simon Wright 2 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-03 21:08 UTC (permalink / raw) <patrick@spellingbeewinnars.org> wrote in message news:6cb6e781-c6df-4962-99e3-760e7c7fab88@googlegroups.com... > Hi Everyone > > I am not understanding user defined exceptions. This little program will > ask the user for integer entry twice. If I type 1 at the first entry, > things work as expected and the exception is handled. > > However if I type, 2 and then 1, an exception is not raised at the second > text_io.get. > > If we type something like : > if x = 1 > then > raise Foo_Error; > end if ; > > will x not be tested for exceptions conditions automatically from that > point onward? No. Why would you think so? The above is just normal code that is executed when it is encountered in the statement stream. It doesn't have any magic properties. Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-03 21:08 ` Randy Brukardt @ 2017-02-03 22:41 ` patrick 0 siblings, 0 replies; 28+ messages in thread From: patrick @ 2017-02-03 22:41 UTC (permalink / raw) hmmmm, thank you Randy. Basically, we could achieve the same thing with just plain variables and a goto set up as well then. It's pretty straight forward after all. Thanks for taking the time to post ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-03 20:27 I am not understanding user defined exceptions patrick 2017-02-03 21:08 ` Randy Brukardt @ 2017-02-04 1:26 ` Dennis Lee Bieber 2017-02-04 6:58 ` J-P. Rosen 2017-02-04 8:41 ` Simon Wright 2 siblings, 1 reply; 28+ messages in thread From: Dennis Lee Bieber @ 2017-02-04 1:26 UTC (permalink / raw) On Fri, 3 Feb 2017 12:27:09 -0800 (PST), patrick@spellingbeewinnars.org declaimed the following: > >If we type something like : > if x = 1 > then > raise Foo_Error; > end if ; > >will x not be tested for exceptions conditions automatically from that point onward? If so, why would it not raise an exception if the second text_io.get came back with 1 ? > No... because that is just a sequence of statements that only take effect /at that location/. Ada doesn't magically go back and apply that code whenever you do something with the variable X. If you always need to have input of a 1 raise the exception, you need to encapsulate the input with the test. See below: -=-=-=-=-=- with Ada.Integer_Text_Io; with Ada.Text_IO; procedure Test_Exceptions is Foo_Error : exception; X : Integer; procedure Get_Int (An_Int : out Integer) is begin Ada.Text_IO.Put ("Enter an integer => "); Ada.Integer_Text_IO.Get (An_Int); if An_Int = 1 then raise Foo_Error; end if; end Get_Int; begin Get_Int (X); -- first input point Get_Int (X); -- second input point Ada.Text_Io.Put_Line ("Ended without exceptions..."); exception when Foo_Error => Ada.Text_Io.Put_Line ("Error handled..."); end Test_Exceptions; -=-=-=-=-=- C:\Users\Wulfraed\Ada>test_exceptions Enter an integer => 1 Error handled... C:\Users\Wulfraed\Ada>test_exceptions Enter an integer => 2 Enter an integer => 1 Error handled... C:\Users\Wulfraed\Ada>test_exceptions Enter an integer => 3 Enter an integer => 2 Ended without exceptions... -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-04 1:26 ` Dennis Lee Bieber @ 2017-02-04 6:58 ` J-P. Rosen 2017-02-04 17:08 ` Simon Wright 0 siblings, 1 reply; 28+ messages in thread From: J-P. Rosen @ 2017-02-04 6:58 UTC (permalink / raw) Le 04/02/2017 à 02:26, Dennis Lee Bieber a écrit : > If you always need to have input of a 1 raise the exception, you need > to encapsulate the input with the test. See below: Or is the logic of your program is that x should never contain 1, declare a subtype with that property: subtype Exclude_One is integer with static_predicate Exclude_One /= 1; and declare x of that subtype. The predicate will be checked every time you set the value of x. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-04 6:58 ` J-P. Rosen @ 2017-02-04 17:08 ` Simon Wright 2017-02-08 17:55 ` Georg Bauhaus 0 siblings, 1 reply; 28+ messages in thread From: Simon Wright @ 2017-02-04 17:08 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > subtype Exclude_One is integer with static_predicate Exclude_One /= 1; My version with Dynamic_Predicate works, but (having checked with John Barnes' book) I see I was being too cautious. Having read over that, I have to say that the GNAT approach (just Predicate, the compiler knows which one to choose) seems the right one to me! ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-04 17:08 ` Simon Wright @ 2017-02-08 17:55 ` Georg Bauhaus 2017-02-08 23:37 ` Randy Brukardt 2017-02-09 0:36 ` Robert A Duff 0 siblings, 2 replies; 28+ messages in thread From: Georg Bauhaus @ 2017-02-08 17:55 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote: > "J-P. Rosen" <rosen@adalog.fr> writes: > >> subtype Exclude_One is integer with static_predicate Exclude_One /= 1; > > My version with Dynamic_Predicate works, but (having checked with John > Barnes' book) I see I was being too cautious. > > Having read over that, I have to say that the GNAT approach (just > Predicate, the compiler knows which one to choose) seems the right one > to me! > Does it work in the static sense when, e.g. a case statement needs to cover precisely the values of Exclude_One at compile time? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-08 17:55 ` Georg Bauhaus @ 2017-02-08 23:37 ` Randy Brukardt 2017-02-09 19:08 ` Robert A Duff 2017-02-09 0:36 ` Robert A Duff 1 sibling, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-08 23:37 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote: > "J-P. Rosen" <rosen@adalog.fr> writes: > >> subtype Exclude_One is integer with static_predicate Exclude_One /= 1; > > My version with Dynamic_Predicate works, but (having checked with John > Barnes' book) I see I was being too cautious. > > Having read over that, I have to say that the GNAT approach (just > Predicate, the compiler knows which one to choose) seems the right one > to me! The GNAT approach causes a very significant maintenance hazard: if you depend on the static properties of a predicate, a seemingly innocous change can break a lot of code. (And that code may not even be yours, if the predicate is in a specification of a shared library. Imagine someone changing a predicate in the specifications of GDKAda that changes it from static to dynamic; a lot of other people's code would break and they'd have no understanding of why (or any hope of fixing it). By declaring your intent as static or dynamic, clients can properly use the predicate subtype and you as the maintainer can't break their expectations without at least realizing that there is a potential problem. This is especially true as many expressions that *seem* simple aren't allowed as static predicates (simple math operators aren't allowed, for instance). After all, a static predicate is a (bizarre) way to describe a set constraint, whereas a dynamic predicate is an implicitly inserted assertion. Quite different semantically. Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-08 23:37 ` Randy Brukardt @ 2017-02-09 19:08 ` Robert A Duff 2017-02-09 21:47 ` Randy Brukardt 0 siblings, 1 reply; 28+ messages in thread From: Robert A Duff @ 2017-02-09 19:08 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > The GNAT approach causes a very significant maintenance hazard: if you > depend on the static properties of a predicate, a seemingly innocous change > can break a lot of code. (And that code may not even be yours, if the > predicate is in a specification of a shared library. Imagine someone > changing a predicate in the specifications of GDKAda that changes it from > static to dynamic; a lot of other people's code would break ... I don't buy it (as you may remember, because I said so in an ARG meeting). The reason is that all these horrible things you mention can happen when you change a static predicate to a different static predicate. E.g.: subtype S is Integer with Static_Predicate => S >= 0; If you change it to: subtype S is Integer with Static_Predicate => S >= 1; client code is just as likely to break as if you changed it to a dynamic predicate. So what? Any time you change the visible part of a widely used library unit, you have to be careful about breaking clients. Note that the first S above is exactly the same as: subtype S is Integer range 0 .. Integer'Last; And we don't bother to mark that as a static range. You could change it to "0 .. Dynamic_Value", and break clients. >...and they'd have > no understanding of why (or any hope of fixing it). Now that's REALLY overstating the case. Anybody who can read Ada code can understand why (and hope to fix it). >... By declaring your intent > as static or dynamic, clients can properly use the predicate subtype and you > as the maintainer can't break their expectations without at least realizing > that there is a potential problem. The above argument proves that to be wrong -- the maintainer CAN break clients DESPITE the fact that the predicate is marked Static_. > This is especially true as many expressions that *seem* simple aren't > allowed as static predicates (simple math operators aren't allowed, for > instance). After all, a static predicate is a (bizarre) way to describe a > set constraint, whereas a dynamic predicate is an implicitly inserted > assertion. Quite different semantically. In the same sense that a static constant is quite different from a dynamic one. For example you can say "when X =>" in a case statement if X is static. And if somebody changes X to a different static value, or to a dynamic value, the case statement will become illegal. - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 19:08 ` Robert A Duff @ 2017-02-09 21:47 ` Randy Brukardt 2017-02-09 22:52 ` Robert A Duff 0 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-09 21:47 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wcco9ybfahw.fsf@TheWorld.com... ... E.g.: > > subtype S is Integer with Static_Predicate => S >= 0; > > If you change it to: > > subtype S is Integer with Static_Predicate => S >= 1; > > client code is just as likely to break as if you changed it > to a dynamic predicate. It's surely possible to have client code break, but it is far less likely if the client used the abstraction as intended. When one goes from a static to a dynamic predicate, all client code using for loops and case statements will fail. Period. When one changes the details of a static predicate, the only code that might fail (statically) is use in a case statement. And such problems generally point out issues with the use of the abstraction (presuming of course that the abstraction was sensibly defined in the first place). For instance, if one had used static predicates to partition a type: subtype Part1 is Integer with Static_Predicate => Part1 >= 0; subtype Part2 is Integer with Static_Predicate => Part2 < 0; then a case statement using the partitions would continue to work if what exactly is in each partition is changed. If, on the other hand, a case statement assumed which partition a particular value belongs, then it might fail if that is changed down the road. But that clearly broke the abstraction, so the failure seems like a good thing in such a case. Clearly, there are far fewer possiblities of failure when one changes a values in a static predicate than when one changes from a static predicate to a dynamic one. So that argument does not hold much water. > So what? Any time you change the > visible part of a widely used library unit, you have to be > careful about breaking clients. The more help that we can give the maintainer to prevent such problems, the better. This is an area where Ada does not do very well, as things that usually don't matter (parameter subtypes, for instance) come into play in some obscure rules and thus virtually any change to a specification will break some code. This is a serious problem; once a library gets into wide use its specification is effectively encased in amber. You have to start over to make any significant changes. I don't see any point in making new features be even worse for that than the existing ones. Luckily, the ARG agreed. > Note that the first S above is exactly the same as: > > subtype S is Integer range 0 .. Integer'Last; > > And we don't bother to mark that as a static range. > You could change it to "0 .. Dynamic_Value", and break > clients. Right. And I as I mentioned elsewhere, we should have done that. (Actually, what we should have done is required one to mark dynamic subtypes, as they're not very likely. Definitely too late for that, though.) >>...and they'd have >> no understanding of why (or any hope of fixing it). > > Now that's REALLY overstating the case. Anybody who can read Ada code > can understand why (and hope to fix it). It's a bit of an overstatement, but it's close: "no understanding why" => there's no indication in the source code (if you use GNAT's evil "predicate") and the rules for when it is static are not intuitive. There's almost no chance that I would think of such a predicate change when I first saw such a problem, I would waste a lot of time looking elsewhere first. And there's no hope of fixing it because it happened in reusable code that they have no control over. They've unintentionally depended on a property that the library did not intend to make stable. The only fix is to totally replace the failing constructs with different ones (and in the case case :-) losing the completeness checks at the same time. >>... By declaring your intent >> as static or dynamic, clients can properly use the predicate subtype and >> you >> as the maintainer can't break their expectations without at least >> realizing >> that there is a potential problem. > > The above argument proves that to be wrong -- the maintainer CAN > break clients DESPITE the fact that the predicate is marked > Static_. Only clients that misused the abstraction in case statements. (For loops won't break, at least not statically -- and if the loop depends on the exact values that it iterates over, they've again missed the point of the abstraction.) I'm definitely less concerned about breakage in iffy code than I am about breakage that occurs in perfect code. Being forced to replace: case Something is when Part1 => ... when Part2 => ... end case; with a less safe if statement just because someone screwed up seems horrible to me. >> This is especially true as many expressions that *seem* simple aren't >> allowed as static predicates (simple math operators aren't allowed, for >> instance). After all, a static predicate is a (bizarre) way to describe a >> set constraint, whereas a dynamic predicate is an implicitly inserted >> assertion. Quite different semantically. > > In the same sense that a static constant is quite different from a > dynamic one. For example you can say "when X =>" in a case > statement if X is static. And if somebody changes X to a different > static value, or to a dynamic value, the case statement will > become illegal. Right, and I view this as a signicificant flaw in Ada. If I was designing a language from scratch, these would clearly be marked as different things. Most likely: X : Integer := ...; -- Static constant X : constant Integer := ...; -- Non-static constant X : variable Integer := ...; -- Variable. Since the default should be the safest thing. (Note that an initializer would be required for all of these; <> could be used to explicitly mark it as default-initialized.) The same with subtypes (anything that has a name). We can't make this change to Ada for obvious reasons, but surely two wrongs do not make a right. Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 21:47 ` Randy Brukardt @ 2017-02-09 22:52 ` Robert A Duff 2017-02-10 9:52 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Robert A Duff @ 2017-02-09 22:52 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Most likely: > > X : Integer := ...; -- Static constant > X : constant Integer := ...; -- Non-static constant > X : variable Integer := ...; -- Variable. > > Since the default should be the safest thing. Well, at least we agree on one thing. It's odd that Ada got it right for parameters ('in' is the default), but got it wrong for object declarations (variable is the default). I'd be happy with: X : Integer := ...; -- constant X : var Integer := ...; -- variable - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 22:52 ` Robert A Duff @ 2017-02-10 9:52 ` Simon Wright 2017-02-10 10:11 ` Dmitry A. Kazakov 2017-02-10 20:56 ` Randy Brukardt 2017-02-10 21:09 ` Randy Brukardt 2 siblings, 1 reply; 28+ messages in thread From: Simon Wright @ 2017-02-10 9:52 UTC (permalink / raw) Robert A Duff <bobduff@TheWorld.com> writes: > X : var Integer := ...; -- variable I suppose one could say X : not constant Integer := ...; (in the interests of minimising the number of keywords), but eewww :-) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-10 9:52 ` Simon Wright @ 2017-02-10 10:11 ` Dmitry A. Kazakov 0 siblings, 0 replies; 28+ messages in thread From: Dmitry A. Kazakov @ 2017-02-10 10:11 UTC (permalink / raw) On 10/02/2017 10:52, Simon Wright wrote: > Robert A Duff <bobduff@TheWorld.com> writes: > >> X : var Integer := ...; -- variable > > I suppose one could say > > X : not constant Integer := ...; > > (in the interests of minimising the number of keywords), but eewww :-) X : in out Integer := ...; -- Error if no initial value X : out Integer; -- Explicitly uninitialized -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 22:52 ` Robert A Duff 2017-02-10 9:52 ` Simon Wright @ 2017-02-10 20:56 ` Randy Brukardt 2017-02-10 21:09 ` Randy Brukardt 2 siblings, 0 replies; 28+ messages in thread From: Randy Brukardt @ 2017-02-10 20:56 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wccfujnf042.fsf@TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> Most likely: >> >> X : Integer := ...; -- Static constant >> X : constant Integer := ...; -- Non-static constant >> X : variable Integer := ...; -- Variable. >> >> Since the default should be the safest thing. > > Well, at least we agree on one thing. It's odd that Ada got it right > for parameters ('in' is the default), but got it wrong for object > declarations (variable is the default). > > I'd be happy with: > > X : Integer := ...; -- constant > X : var Integer := ...; -- variable > > - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 22:52 ` Robert A Duff 2017-02-10 9:52 ` Simon Wright 2017-02-10 20:56 ` Randy Brukardt @ 2017-02-10 21:09 ` Randy Brukardt 2017-02-10 22:07 ` Dmitry A. Kazakov 2017-02-10 23:53 ` Shark8 2 siblings, 2 replies; 28+ messages in thread From: Randy Brukardt @ 2017-02-10 21:09 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wccfujnf042.fsf@TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> Most likely: >> >> X : Integer := ...; -- Static constant >> X : constant Integer := ...; -- Non-static constant >> X : variable Integer := ...; -- Variable. >> >> Since the default should be the safest thing. > > Well, at least we agree on one thing. It's odd that Ada got it right > for parameters ('in' is the default), but got it wrong for object > declarations (variable is the default). > > I'd be happy with: > > X : Integer := ...; -- constant > X : var Integer := ...; -- variable (1) Ada doesn't generally use abbreviations, thus "var" isn't a likely keyword. (2) It's important that all properties that clients can depend upon are declarable, so clients aren't depending on accidental properties. (That's the whole principle behind private types.) Static is such a property, so it should be declarable (not necessarily have to be declared in all cases). [Indeed, it should be possible to declare static private types - a whole different kettle of fish.] Similarly, it would be nice if there was a way to prevent people from depending upon the subtype profile of a subprogram (so that it can later be changed if necessary). There's probably other such properties (one would like to include formal parameter names in this sort of restriction, but that would prevent named calls which would be evil.) Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-10 21:09 ` Randy Brukardt @ 2017-02-10 22:07 ` Dmitry A. Kazakov 2017-02-13 23:20 ` Randy Brukardt 2017-02-10 23:53 ` Shark8 1 sibling, 1 reply; 28+ messages in thread From: Dmitry A. Kazakov @ 2017-02-10 22:07 UTC (permalink / raw) On 2017-02-10 22:09, Randy Brukardt wrote: > (2) It's important that all properties that clients can depend upon are > declarable, so clients aren't depending on accidental properties. (That's > the whole principle behind private types.) Static is such a property, Why is static a property? Not to confuse with immutability. Mutability is a property (a subtype), observable through operations being visible or not. Staticness looks like a language design artifact. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-10 22:07 ` Dmitry A. Kazakov @ 2017-02-13 23:20 ` Randy Brukardt 2017-02-14 8:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-13 23:20 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:o7ldjo$10aj$1@gioia.aioe.org... > On 2017-02-10 22:09, Randy Brukardt wrote: > >> (2) It's important that all properties that clients can depend upon are >> declarable, so clients aren't depending on accidental properties. (That's >> the whole principle behind private types.) Static is such a property, > > Why is static a property? > > Not to confuse with immutability. Mutability is a property (a subtype), > observable through operations being visible or not. Staticness looks like > a language design artifact. Its a property because the language design depends on it so heavily. Perhaps one could design a language that enforced Legality Rules without having some property that controls whether that is possible or not, but I can't quite imagine how. (Only a language that enforced no rules until runtime could work that way, IMHO, and that eliminates most of the benefits of strong typing and early error detection.) If static was a declarable property, I'd also make it possible to declare user-defined static things, and apply that to all types. For instance, it should be possible to have static System.Address values, static Complex values, and the like. It wouldn't be limited to just whatever the language designers could define. Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-13 23:20 ` Randy Brukardt @ 2017-02-14 8:39 ` Dmitry A. Kazakov 2017-02-14 20:07 ` Randy Brukardt 0 siblings, 1 reply; 28+ messages in thread From: Dmitry A. Kazakov @ 2017-02-14 8:39 UTC (permalink / raw) On 14/02/2017 00:20, Randy Brukardt wrote: > If static was a declarable property, I'd also make it possible to declare > user-defined static things, and apply that to all types. For instance, it > should be possible to have static System.Address values, static Complex > values, and the like. It wouldn't be limited to just whatever the language > designers could define. What about pure operations? The result of a pure operation with static arguments is static, you don't need to declare anything upfront. Static subtype does not make much sense unless you split implicit value-getter primitive operation into two: one yields the object's static value, another does the object's dynamic value. However, if you let them being overridden independently you might get an interesting set of possibilities, e.g. building static hash tables, indexing constant strings etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-14 8:39 ` Dmitry A. Kazakov @ 2017-02-14 20:07 ` Randy Brukardt 2017-02-15 9:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-14 20:07 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:o7ufnn$1oq5$1@gioia.aioe.org... > On 14/02/2017 00:20, Randy Brukardt wrote: > >> If static was a declarable property, I'd also make it possible to declare >> user-defined static things, and apply that to all types. For instance, it >> should be possible to have static System.Address values, static Complex >> values, and the like. It wouldn't be limited to just whatever the >> language >> designers could define. > > What about pure operations? The result of a pure operation with static > arguments is static, you don't need to declare anything upfront. Not really, unless you are going to require the compiler to be able to interpret any arbitrary code (local variables, loops, gotos, etc.) whether a particular function can be static depends on the body. Thus you have to declare on the specification whether it can be used as a static function. > Static subtype does not make much sense unless you split implicit > value-getter primitive operation into two: one yields the object's static > value, another does the object's dynamic value. However, if you let them > being overridden independently you might get an interesting set of > possibilities, e.g. building static hash tables, indexing constant strings > etc. Exactly, other than I would say that there always has to be a dynamic value routine and the static value routine has to yield the "same" value (whatever "same" means in this context - that also could be user-defined) for the same arguments. Randy. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-14 20:07 ` Randy Brukardt @ 2017-02-15 9:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 28+ messages in thread From: Dmitry A. Kazakov @ 2017-02-15 9:32 UTC (permalink / raw) On 2017-02-14 21:07, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> What about pure operations? The result of a pure operation with static >> arguments is static, you don't need to declare anything upfront. > > Not really, unless you are going to require the compiler to be able to > interpret any arbitrary code (local variables, loops, gotos, etc.) whether a > particular function can be static depends on the body. Thus you have to > declare on the specification whether it can be used as a static function. Rather a declaration that the implementation is (must be) pure inside some context, e.g. within a package or parent subprogram. Static is a case when it is pure in the most wide context, everywhere. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-10 21:09 ` Randy Brukardt 2017-02-10 22:07 ` Dmitry A. Kazakov @ 2017-02-10 23:53 ` Shark8 1 sibling, 0 replies; 28+ messages in thread From: Shark8 @ 2017-02-10 23:53 UTC (permalink / raw) On Friday, February 10, 2017 at 2:09:36 PM UTC-7, Randy Brukardt wrote: > "Robert A Duff"wrote in message > news:wccfujnf042.fsf... > > "Randy Brukardt" writes: > > > >> Most likely: > >> > >> X : Integer := ...; -- Static constant > >> X : constant Integer := ...; -- Non-static constant > >> X : variable Integer := ...; -- Variable. > >> > >> Since the default should be the safest thing. > > > > Well, at least we agree on one thing. It's odd that Ada got it right > > for parameters ('in' is the default), but got it wrong for object > > declarations (variable is the default). > > > > I'd be happy with: > > > > X : Integer := ...; -- constant > > X : var Integer := ...; -- variable > > (1) Ada doesn't generally use abbreviations, thus "var" isn't a likely > keyword. > > (2) It's important that all properties that clients can depend upon are > declarable, so clients aren't depending on accidental properties. (That's > the whole principle behind private types.) Static is such a property, so it > should be declarable (not necessarily have to be declared in all cases). > [Indeed, it should be possible to declare static private types - a whole > different kettle of fish.] Similarly, it would be nice if there was a way to > prevent people from depending upon the subtype profile of a subprogram (so > that it can later be changed if necessary). There's probably other such > properties (one would like to include formal parameter names in this sort of > restriction, but that would prevent named calls which would be evil.) > > Randy. Randy, have you any experience with VHDL? Some of what you're saying seems to have been done in VHDL. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-08 17:55 ` Georg Bauhaus 2017-02-08 23:37 ` Randy Brukardt @ 2017-02-09 0:36 ` Robert A Duff 2017-02-09 7:43 ` Simon Wright 1 sibling, 1 reply; 28+ messages in thread From: Robert A Duff @ 2017-02-09 0:36 UTC (permalink / raw) Georg Bauhaus <nonlegitur@futureapps.invalid> writes: > Does it work in the static sense when, e.g. a case > statement needs to cover precisely the values of > Exclude_One at compile time? Yes. In GNAT, Predicate is equivalent to Static_Predicate if that would be legal, otherwise it's equivalent to Dynamic_Predicate. You get all the nice full coverage rules in case statements and array aggregates and so forth. - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 0:36 ` Robert A Duff @ 2017-02-09 7:43 ` Simon Wright 2017-02-09 19:15 ` Robert A Duff 0 siblings, 1 reply; 28+ messages in thread From: Simon Wright @ 2017-02-09 7:43 UTC (permalink / raw) Robert A Duff <bobduff@TheWorld.com> writes: > Georg Bauhaus <nonlegitur@futureapps.invalid> writes: > >> Does it work in the static sense when, e.g. a case >> statement needs to cover precisely the values of >> Exclude_One at compile time? > > Yes. In GNAT, Predicate is equivalent to Static_Predicate if that > would be legal, otherwise it's equivalent to Dynamic_Predicate. You > get all the nice full coverage rules in case statements and array > aggregates and so forth. Good, but I have to admit the strength of Randy's point re: maintainability. Would it be possible for GNAT have a diagnostic option to state whether explicit Static_Predicate would be OK? (you could tell me to just try Static_Predicate first!) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 7:43 ` Simon Wright @ 2017-02-09 19:15 ` Robert A Duff 2017-02-09 20:39 ` Randy Brukardt 2017-02-09 21:06 ` Randy Brukardt 0 siblings, 2 replies; 28+ messages in thread From: Robert A Duff @ 2017-02-09 19:15 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Good, but I have to admit the strength of Randy's point re: > maintainability. I don't share Randy's concerns about maintainability. >...Would it be possible for GNAT have a diagnostic option > to state whether explicit Static_Predicate would be OK? Sure, but I'm not likely to implement any such thing, given my opinion expressed above. I recommend you use "Predicate =>" unless you want to be portable to non-GNAT compilers (or request the other compilers to mimic GNAT). To convince me otherwise, you'll have to explain why we don't say: X: static constant Integer := 100; static subtype S is Integer range 1..100; >...(you could tell > me to just try Static_Predicate first!) Sure, you can do that if you like. To me, "Static_" is just noise (or necessary for portability). This kind of inconsistency is a flaw in the design of Ada. - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 19:15 ` Robert A Duff @ 2017-02-09 20:39 ` Randy Brukardt 2017-02-09 21:06 ` Randy Brukardt 1 sibling, 0 replies; 28+ messages in thread From: Randy Brukardt @ 2017-02-09 20:39 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wcck28zfa69.fsf@TheWorld.com... > Simon Wright <simon@pushface.org> writes: > >> Good, but I have to admit the strength of Randy's point re: >> maintainability. > > I don't share Randy's concerns about maintainability. > >>...Would it be possible for GNAT have a diagnostic option >> to state whether explicit Static_Predicate would be OK? > > Sure, but I'm not likely to implement any such thing, > given my opinion expressed above. I recommend you use > "Predicate =>" unless you want to be portable to non-GNAT > compilers (or request the other compilers to mimic GNAT). > > To convince me otherwise, you'll have to explain why we don't say: > > X: static constant Integer := 100; > static subtype S is Integer range 1..100; > >>...(you could tell >> me to just try Static_Predicate first!) > > Sure, you can do that if you like. To me, "Static_" is just noise > (or necessary for portability). This kind of inconsistency is > a flaw in the design of Ada. > > - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 19:15 ` Robert A Duff 2017-02-09 20:39 ` Randy Brukardt @ 2017-02-09 21:06 ` Randy Brukardt 2017-02-09 23:08 ` Robert A Duff 1 sibling, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2017-02-09 21:06 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wcck28zfa69.fsf@TheWorld.com... ... > To convince me otherwise, you'll have to explain why we don't say: > > X: static constant Integer := 100; > static subtype S is Integer range 1..100; We've had this discussion before: (1) We don't have it because Ichibiah left it out. I think that was a mistake. (2) For the constant, you can declare it to be static and I usually do: X: constant := 100; It's unfortunate that you can declare an object to be static or give it a type, but not both. This kind of inconsistency is a flaw in the design of Ada. ;-) (3) Ada really does need such a capability. Staticness determines many Legality Rules and it can be a critical property when exposed in a reusable library. Unintentionally eliminating it can be disasterous for clients. I'd definitely be in favor of adding the "static" keyword as you have it above. (It would have to be optional, sadly, but of course a restriction could "fix" that.) But arguably it is much less likely to be changed by accident (although it has happened to me repeatedly) -- almost every operation that you'd expect to be static can be static (the main exception being representation attributes like Size). That's definitely not the case with Static_Predicates. (4) <rant> GNAT effectively nullifying a carefully considered and heavily debated decision in the ARG because a couple of people didn't like it is about the most evil behavior that an implementer could take. It's the sort of thing that makes me wonder why AdaCore is so invested in the Standards process if it just going to ignore the result when convinient. </rant> >>...(you could tell me to just try Static_Predicate first!) > > Sure, you can do that if you like. To me, "Static_" is just noise > (or necessary for portability). This kind of inconsistency is > a flaw in the design of Ada. You're just plain wrong, considering that we discussed this extensively in the ARG and the "maintenance is important" position carried the day. The flaw is that you can't declare most things static to avoid future problems. Randy. P.S. Side note: as with "constant", "static" probably should have been the default. It really should be necessary to declare something non-static or variable. That would be possible in a totally brand-new language, but sadly not in Ada or even an improved Ada-like language. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-09 21:06 ` Randy Brukardt @ 2017-02-09 23:08 ` Robert A Duff 0 siblings, 0 replies; 28+ messages in thread From: Robert A Duff @ 2017-02-09 23:08 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > (4) <rant> GNAT effectively nullifying a carefully considered and heavily > debated decision in the ARG because a couple of people didn't like it is > about the most evil behavior that an implementer could take. ... First of all, compiler vendors can provide whatever extensions they like, and there's nothing "evil" about that. If you don't want to use extensions, don't, and select the options that give you an error if you use extensions by accident. GNAT fully supports the standard Static_Predicate and Dynamic_Predicate. Second of all, if I remember the history correctly, GNAT implemented this feature as originally designed, which was Predicate. Then ARG stepped in and changed that design, so GNAT implemented the other two attributes. It seems perfectly reasonable to me to also keep the Predicate aspect, since people were already using it. > You're just plain wrong, considering that we discussed this extensively in > the ARG and the "maintenance is important" position carried the day. The > flaw is that you can't declare most things static to avoid future problems. Sorry, but majority rule doesn't prove that anyone is "just plain wrong". I realize my opinion is in the minority (of ARG anyway), but I still think I'm right on this point. (Of course I do -- if I thought I was wrong, I would change my mind!) You are using sophistry when you say "maintenance is important". Of course I agree that maintenance is important; characterizing my opinion as anti-maintenance is "just plain wrong". ;-) - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: I am not understanding user defined exceptions 2017-02-03 20:27 I am not understanding user defined exceptions patrick 2017-02-03 21:08 ` Randy Brukardt 2017-02-04 1:26 ` Dennis Lee Bieber @ 2017-02-04 8:41 ` Simon Wright 2 siblings, 0 replies; 28+ messages in thread From: Simon Wright @ 2017-02-04 8:41 UTC (permalink / raw) You are thinking of user-defined *predicates* (properties of values of the type), available in Ada2012. Try subtype Not_One is Integer with Dynamic_Predicate => Not_One /= 1; X : Not_One; (with GNAT, you have to enable assertion checking, compile with -gnata) $ ./test_exceptions 2 1 raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : Dynamic_Predicate failed at test_exceptions.adb:9 (line 9 is the second Get) ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2017-02-15 9:32 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-03 20:27 I am not understanding user defined exceptions patrick 2017-02-03 21:08 ` Randy Brukardt 2017-02-03 22:41 ` patrick 2017-02-04 1:26 ` Dennis Lee Bieber 2017-02-04 6:58 ` J-P. Rosen 2017-02-04 17:08 ` Simon Wright 2017-02-08 17:55 ` Georg Bauhaus 2017-02-08 23:37 ` Randy Brukardt 2017-02-09 19:08 ` Robert A Duff 2017-02-09 21:47 ` Randy Brukardt 2017-02-09 22:52 ` Robert A Duff 2017-02-10 9:52 ` Simon Wright 2017-02-10 10:11 ` Dmitry A. Kazakov 2017-02-10 20:56 ` Randy Brukardt 2017-02-10 21:09 ` Randy Brukardt 2017-02-10 22:07 ` Dmitry A. Kazakov 2017-02-13 23:20 ` Randy Brukardt 2017-02-14 8:39 ` Dmitry A. Kazakov 2017-02-14 20:07 ` Randy Brukardt 2017-02-15 9:32 ` Dmitry A. Kazakov 2017-02-10 23:53 ` Shark8 2017-02-09 0:36 ` Robert A Duff 2017-02-09 7:43 ` Simon Wright 2017-02-09 19:15 ` Robert A Duff 2017-02-09 20:39 ` Randy Brukardt 2017-02-09 21:06 ` Randy Brukardt 2017-02-09 23:08 ` Robert A Duff 2017-02-04 8:41 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox