I am not understanding user defined exceptions

I am not understanding user defined exceptions

[patrick]

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;

Re: I am not understanding user defined exceptions

[Randy Brukardt]

<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.

Re: I am not understanding user defined exceptions

[patrick]

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

Re: I am not understanding user defined exceptions

[Dennis Lee Bieber]

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/

Re: I am not understanding user defined exceptions

[J-P. Rosen]

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

Re: I am not understanding user defined exceptions

[Simon Wright]

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)

Re: I am not understanding user defined exceptions

[Simon Wright]

"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!

Re: I am not understanding user defined exceptions

[Georg Bauhaus]

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?

Re: I am not understanding user defined exceptions

[Randy Brukardt]

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.

Re: I am not understanding user defined exceptions

[Robert A Duff]

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

Re: I am not understanding user defined exceptions

[Simon Wright]

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!)

Re: I am not understanding user defined exceptions

[Robert A Duff]

"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

Re: I am not understanding user defined exceptions

[Robert A Duff]

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

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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 

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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.

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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.

Re: I am not understanding user defined exceptions

[Robert A Duff]

"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

Re: I am not understanding user defined exceptions

[Robert A Duff]

"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

Re: I am not understanding user defined exceptions

[Simon Wright]

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 :-)

Re: I am not understanding user defined exceptions

[Dmitry A. Kazakov]

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

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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 

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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.

Re: I am not understanding user defined exceptions

[Dmitry A. Kazakov]

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

Re: I am not understanding user defined exceptions

[Shark8]

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.

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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.

Re: I am not understanding user defined exceptions

[Dmitry A. Kazakov]

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

Re: I am not understanding user defined exceptions

[Randy Brukardt]

"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.

Re: I am not understanding user defined exceptions

[Dmitry A. Kazakov]

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