About String

About String

[Sébastien Morand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm curious about how you are using string. I think string are quite
useful, but how they are fixed size, I'm often defining them in the
declare part.

I don't know if it's a good practice, but I got code like this:

      urio: constant AWS.URL.Object := AWS.Status.URI(request);
      host_raw: constant String := AWS.Status.Host(request);
      host: constant String := host_raw(host_raw'First ..
First_Index(host_raw, ':'));
      www: constant String := SCMAL.Httpd.Servers.GetWWW(host);
      Filename: constant String := AWS.URL.Abs_Path(urio);

and so on.

So the main problem is error management. If one function raise
exception, the exception can't be catch except with the following trick:

procedure Patati_Patata is
begin
	declare
		s: String := A_Function_Raising_Constraint_Error;
	begin
		--  some code
		null;
	end;
exception
	when Constraint_Error =>
		Put_Line("I got an error");
end;

Is there nicer way to do that? I'm trying to avoid Unbounded_String
because of the conversion when mixing Unbounded_String and String.

S�bastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFISXQH+zV9xm4PlDQRAp1AAJ98x/YTeiFzGP4PGJeL+7B2+iLtRQCggbzh
Xcv5gRRjhmFVnCqVVQRk4QM=
=tG7M
-----END PGP SIGNATURE-----

Re: About String

[Simon Wright]

S�bastien Morand <seb.morand@gmail.com> writes:

> So the main problem is error management. If one function raise
> exception, the exception can't be catch except with the following trick:

I don't know why you call it a trick! Perfectly standard Ada ...

> procedure Patati_Patata is
> begin
> 	declare
> 		s: String := A_Function_Raising_Constraint_Error;
> 	begin
> 		--  some code
> 		null;
> 	end;
> exception
> 	when Constraint_Error =>
> 		Put_Line("I got an error");
> end;
>
> Is there nicer way to do that? I'm trying to avoid Unbounded_String
> because of the conversion when mixing Unbounded_String and String.

You might want to handle the problem locally:

   procedure Patati_Patata is
   begin
      declare
         S : String := A_Function_Raising_Constraint_Error;
      begin
         --  some code
      exception
         when Constraint_Error =>
            --  deal with the problem and carry on ..
      end;
      --  .. here
   end Patati_Patata;

In general I don't like exception handlers which output a message and
then allow the procedure to look as though it has succeeded when in
fact something unforeseen has occurred, and is waiting to cause
mysterious problems much much later. Exceptions to this guideline
could include 'last-chance' exception handlers in tasks and the main
program; but if you are controlling missiles, medical equipment or
money it's probably better not to just stumble on in the hope that
things will turn out all right.

Re: About String

[Pascal Obry]

Simon Wright a �crit :
> You might want to handle the problem locally:
> 
>    procedure Patati_Patata is
>    begin
>       declare
>          S : String := A_Function_Raising_Constraint_Error;
>       begin
>          --  some code
>       exception
>          when Constraint_Error =>
>             --  deal with the problem and carry on ..
>       end;
>       --  .. here

This one is wrong. The exception on the declare section can't be handled 
on the local block as it will raised outside of the block.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: About String

[Chris Moore]

Pascal Obry wrote:
> Simon Wright a �crit :
>> You might want to handle the problem locally:
>>
>>    procedure Patati_Patata is
>>    begin
>>       declare
>>          S : String := A_Function_Raising_Constraint_Error;
>>       begin
>>          --  some code
>>       exception
>>          when Constraint_Error =>
>>             --  deal with the problem and carry on ..
>>       end;
>>       --  .. here
> 
> This one is wrong. The exception on the declare section can't be handled 
> on the local block as it will raised outside of the block.
> 
> Pascal.
> 

You are correct.  I have to say this is an entirely non-intuitive 
"feature" of the language.  We talk about declare blocks and yet the 
scope of the exception handlers doesn't include the declarations!   And 
the OP is correct in noticing that without the inner declare block 
exceptions raised in the outermost declarative section leak into the 
calling subprogram.  Ugh.

Chris

Re: About String

[Niklas Holsti]

Chris Moore wrote:
> Pascal Obry wrote:
> 
>> Simon Wright a �crit :
>>
>>> You might want to handle the problem locally:
>>>
>>>    procedure Patati_Patata is
>>>    begin
>>>       declare
>>>          S : String := A_Function_Raising_Constraint_Error;
>>>       begin
>>>          --  some code
>>>       exception
>>>          when Constraint_Error =>
>>>             --  deal with the problem and carry on ..
>>>       end;
>>>       --  .. here
>>
>>
>> This one is wrong. The exception on the declare section can't be 
>> handled on the local block as it will raised outside of the block.
>>
>> Pascal.
>>
> 
> You are correct.

Yes.

> I have to say this is an entirely non-intuitive "feature" of the language.

I beg to differ. The program should be read as

     declare <some variables>
     begin <do something with those variables> end;

The exception handler is within the "begin..end" block, not on the 
"declare". (Indenting the "begin..exception..end" structure one 
level beyond the "declare" would make this more visible, but is not 
common practice.)

> We talk about declare blocks and yet the 
> scope of the exception handlers doesn't include the declarations!

The declared variables are visible in the whole "begin..end" block, 
including in the exception handler. If the declarations raise an 
exception, it would be madness to try to handle it within the 
"begin..end" block, because the handler could try to use 
un-elaborated (non-existent) variables.

The solution is just to add one more "begin..end" block, enclosing 
the "declare .. begin .. end", and handle the exceptions in this 
outer "begin..end" block. Or handle the exceptions in the 
subprogram's "begin..end" block and nest the "declare..begin..end" 
within the subprograms "begin..end".

That said, I admit that I, too, have made this mistake once or 
twice. But not lately.

I wonder if it would be a good idea for Ada to allow an exception 
handler also in the "declare" part, as follows:

    -- NOT Ada!
    declare <some variables>
    exception <handle exceptions raised in the declarations>
    begin <some statements>
    exception <handle exceptions raised in the statements>
    end;

Of course, in this proposal the declaration-exception handler would 
not have access to the declared variables.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: About String

[Dmitry A. Kazakov]

On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:

> The solution is just to add one more "begin..end" block, enclosing 
> the "declare .. begin .. end", and handle the exceptions in this 
> outer "begin..end" block. Or handle the exceptions in the 
> subprogram's "begin..end" block and nest the "declare..begin..end" 
> within the subprograms "begin..end".
> 
> That said, I admit that I, too, have made this mistake once or 
> twice. But not lately.

If exceptions were contracted such, quite nasty, errors could be detected
at compile time.

> I wonder if it would be a good idea for Ada to allow an exception 
> handler also in the "declare" part, as follows:
> 
>     -- NOT Ada!
>     declare <some variables>
>     exception <handle exceptions raised in the declarations>
>     begin <some statements>
>     exception <handle exceptions raised in the statements>
>     end;
> 
> Of course, in this proposal the declaration-exception handler would 
> not have access to the declared variables.

But then, for regularity sake, you would need to add exception handling to
all declarative parts:

package A is
    <some declarations>
exception
    <handling elaboration problems of A, HOW?>  (:-))
end A;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Sebastien Morand]

Thanks for all you answer. I m happy to see I did the right way.

Actually not handling exception of the declaring part can be non intuitive at 
first. But I think it is. If you could, you wouldn't know wich data is available 
since you don't know where the exception take place in the declarative part. So 
it's better to handle it externally where you know wich variables are already 
defined. the only matter is that you can handle exception in declarative part of 
a function/procedure. So you have to declare it in subblock and then handle the 
exception. The problem is, if you can't anymore use the string in the body of 
the function, only in the subblock.

Sebastien

Re: About String

[Dmitry A. Kazakov]

On Sun, 08 Jun 2008 10:29:53 +0000, Sebastien Morand wrote:

> The problem is, if you can't anymore use the string in the body of 
> the function, only in the subblock.

Which is absolutely consistent.

Consider it as follows. When the initialization of an object used in the
subprogram body may fail, that means for the body, that there are two
different cases:

1. Object exists, legally initialized of course [case A]
2. No object exists (because it cannot go through initialization) [case B]

This means that the body shall necessarily consist of two parts. Note that
the precondition of B is weaker than one of A. So B can contain A, but not
reverse. Therefore there exist only two variants:

1. A nested in B (this what Ada provides)
2. A side by side with B. This would require some syntax extensions, like
Niklas has outlined, but without obvious advantages.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Simon Wright a �crit :
>> You might want to handle the problem locally:
>>
>>    procedure Patati_Patata is
>>    begin
>>       declare
>>          S : String := A_Function_Raising_Constraint_Error;
>>       begin
>>          --  some code
>>       exception
>>          when Constraint_Error =>
>>             --  deal with the problem and carry on ..
>>       end;
>>       --  .. here
>
> This one is wrong. The exception on the declare section can't be
> handled on the local block as it will raised outside of the block.

:blush:

I meant to say

   procedure Patati_Patata is
   begin
      begin
         declare
            S : String := A_Function_Raising_Constraint_Error;
         begin
            --  some code
         end;
      exception
         when Constraint_Error =>
            --  deal with the problem ..
      end;
      --  .. and carry on
   end;

Re: About String

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:
> 
> 
>>The solution is just to add one more "begin..end" block, enclosing 
>>the "declare .. begin .. end", and handle the exceptions in this 
>>outer "begin..end" block. Or handle the exceptions in the 
>>subprogram's "begin..end" block and nest the "declare..begin..end" 
>>within the subprograms "begin..end".
>>
>>That said, I admit that I, too, have made this mistake once or 
>>twice. But not lately.
> 
> 
> If exceptions were contracted such, quite nasty, errors could be detected
> at compile time.

Only if the programmer specifies the exception contracts separately 
for the declarative parts and the statements. I don't remember any 
such proposals.

>>I wonder if it would be a good idea for Ada to allow an exception 
>>handler also in the "declare" part, as follows:
>>
>>    -- NOT Ada!
>>    declare <some variables>
>>    exception <handle exceptions raised in the declarations>
>>    begin <some statements>
>>    exception <handle exceptions raised in the statements>
>>    end;
>>
>>Of course, in this proposal the declaration-exception handler would 
>>not have access to the declared variables.
> 
> 
> But then, for regularity sake, you would need to add exception handling to
> all declarative parts:

And why not?

> package A is
>     <some declarations>
> exception
>     <handling elaboration problems of A, HOW?>  (:-))
> end A;

It seems, from your smiley, that you feel that such a structure 
would be somehow impossible. I don't see why; the exception handler 
could execute any sort of non-erroneous code that could be executed 
in any subprogram called as part of the declarations in package A. 
For example, it could set some flag in another package to inform 
the application that package A cannot be used because its 
elaboration failed. If the application uses run-time elaboration 
checks, it could even continue executing, as long as it does not 
try to use anything in A. I admit that this might need an extended 
form of run-time elaboration checks.

I'm not suggesting that this feature (exception handlers in package 
declarations) is desirable, but I don't think it would be 
impossible, and it could even be useful in some applications.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: About String

[Martin]

On 8 Jun, 08:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:
> > The solution is just to add one more "begin..end" block, enclosing
> > the "declare .. begin .. end", and handle the exceptions in this
> > outer "begin..end" block. Or handle the exceptions in the
> > subprogram's "begin..end" block and nest the "declare..begin..end"
> > within the subprograms "begin..end".
>
> > That said, I admit that I, too, have made this mistake once or
> > twice. But not lately.
>
> If exceptions were contracted such, quite nasty, errors could be detected
> at compile time.
>
> > I wonder if it would be a good idea for Ada to allow an exception
> > handler also in the "declare" part, as follows:
>
> >     -- NOT Ada!
> >     declare <some variables>
> >     exception <handle exceptions raised in the declarations>
> >     begin <some statements>
> >     exception <handle exceptions raised in the statements>
> >     end;
>
> > Of course, in this proposal the declaration-exception handler would
> > not have access to the declared variables.
>
> But then, for regularity sake, you would need to add exception handling to
> all declarative parts:
>
> package A is
>     <some declarations>
> exception
>     <handling elaboration problems of A, HOW?>  (:-))
> end A;

Admittedly the range of options is pretty limited if exception
handlers where to be added to package specs but you could log an
indication in a package local variable, set a default or re-raise the
exception.

I rather like the idea...that forced nesting just to catch an
exception is quite ugly and dare I day, goes against Ada's "easy to
read and therefore maintain" mantra...

Cheers
-- Martin

Re: About String

[Dmitry A. Kazakov]

On Sun, 08 Jun 2008 14:14:04 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:
>> 
>>>The solution is just to add one more "begin..end" block, enclosing 
>>>the "declare .. begin .. end", and handle the exceptions in this 
>>>outer "begin..end" block. Or handle the exceptions in the 
>>>subprogram's "begin..end" block and nest the "declare..begin..end" 
>>>within the subprograms "begin..end".
>>>
>>>That said, I admit that I, too, have made this mistake once or 
>>>twice. But not lately.
>> 
>> If exceptions were contracted such, quite nasty, errors could be detected
>> at compile time.
> 
> Only if the programmer specifies the exception contracts separately 
> for the declarative parts and the statements. I don't remember any 
> such proposals.

I had this in mind:

function Boo raise Use_Error return String; -- That's not Ada
procedure Foo raise null;

procedure Foo is 
   X : String := Boo;
begin
   ...
exception
   when Use_Error => -- The handler is misplaced
      ...
end Foo;

This won't compile because Use_Error is not handled when propagates out of
Boo. But the contract of Foo promises no Use_Error.

>>>I wonder if it would be a good idea for Ada to allow an exception 
>>>handler also in the "declare" part, as follows:
>>>
>>>    -- NOT Ada!
>>>    declare <some variables>
>>>    exception <handle exceptions raised in the declarations>
>>>    begin <some statements>
>>>    exception <handle exceptions raised in the statements>
>>>    end;
>>>
>>>Of course, in this proposal the declaration-exception handler would 
>>>not have access to the declared variables.
>> 
>> But then, for regularity sake, you would need to add exception handling to
>> all declarative parts:
> 
> And why not?

Because that would make the margin between declarative and imperative more
fuzzy than it already is.

>> package A is
>>     <some declarations>
>> exception
>>     <handling elaboration problems of A, HOW?>  (:-))
>> end A;
> 
> It seems, from your smiley, that you feel that such a structure 
> would be somehow impossible. I don't see why; the exception handler 
> could execute any sort of non-erroneous code that could be executed 
> in any subprogram called as part of the declarations in package A. 
> For example, it could set some flag in another package to inform 
> the application that package A cannot be used because its 
> elaboration failed. If the application uses run-time elaboration 
> checks, it could even continue executing, as long as it does not 
> try to use anything in A. I admit that this might need an extended 
> form of run-time elaboration checks.

There are two models of exception handling:

1. Handle and continue
2. Wind-up then handle

The first was used by PL/1, I cannot tell if it still has it. The second is
Ada's model. It is sufficiently simpler (no upward closures etc) and also
more general, because it allows continuation without fixing.

Fixing a failed declaration would be the first model. I don't see how this
could be made, because the exception handler cannot see failed stuff. Which
is because it is still the second model... They don't live together.

For the second model, it is unclear what will be the status of failed A?
Say, B with-es A and A has failed. That means that B should also fail. But:

with A;
package B is
   ...
exception
   -- I still cannot handle A's failure here!
end B;

So we would need something like exception handlers in with!

with A
   package B
      ...
   end B;
exception
   -- OK, I can handle A's failure, but what happened with B?
end with A;

Nevertheless we still cannot do anything in order to fix B.

It seems that declarations could not be fixed in the second model.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Conditional declarations (was: About String)

[Dmitry A. Kazakov]

On Sun, 8 Jun 2008 04:48:56 -0700 (PDT), Martin wrote:

> On 8 Jun, 08:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> package A is
>> � � <some declarations>
>> exception
>> � � <handling elaboration problems of A, HOW?> �(:-))
>> end A;
> 
> Admittedly the range of options is pretty limited if exception
> handlers where to be added to package specs but you could log an
> indication in a package local variable, set a default or re-raise the
> exception.

Aha, so many people are looking for Ada preprocessor! (:-)) What about
catching compile error in with-ing OS.Linux in order to with OS.Windows
instead? (:-))

> I rather like the idea...that forced nesting just to catch an
> exception is quite ugly and dare I day, goes against Ada's "easy to
> read and therefore maintain" mantra...

I think it could be solved in a different way, together with a closely
related  problem:

   if X in T'Class then
      declare
         TX : T'Class renames T'Class (X);
      begin
         ...
      end;
   end if;

   if Ptr /= null then
      declare
         Ptr_All : T renames Ptr.all;
      begin
         ...
      end;
   end if;

This is a pretty frequent and quite ugly construct, especially because it
verifies the same condition twice.

I think that a fail-safe declaration is in essence a similar thing. It need
not to appear in the main declaration block, because it a combination of a
flow control and visibility scope.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Sun, 08 Jun 2008 14:14:04 +0300, Niklas Holsti wrote:
> 
>>Dmitry A. Kazakov wrote:
>>
>>>On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:

>>> [ About the fact that exceptions raised in a declarative
 >>>   part cannot be handled by the handler in the following
>>>   handled_sequence_of_statements, and it is an error
 >>>   to try. ]
>>>
>>>If exceptions were contracted such, quite nasty, errors could be detected
>>>at compile time.
>>
>>Only if the programmer specifies the exception contracts separately 
>>for the declarative parts and the statements. I don't remember any 
>>such proposals.
> 
> 
> I had this in mind:
> 
> function Boo raise Use_Error return String; -- That's not Ada
> procedure Foo raise null;
> 
> procedure Foo is 
>    X : String := Boo;
> begin
>    ...
> exception
>    when Use_Error => -- The handler is misplaced
>       ...
> end Foo;
> 
> This won't compile because Use_Error is not handled when propagates out of
> Boo. But the contract of Foo promises no Use_Error.

I agree that exception contracts would work in this example. Ok, 
exception contracts would reveal some -- perhaps most -- of these 
errors at compile time, but not all.

>>>>I wonder if it would be a good idea for Ada to allow an exception 
>>>>handler also in the "declare" part, as follows:
>>>>
>>>>   -- NOT Ada!
>>>>   declare <some variables>
>>>>   exception <handle exceptions raised in the declarations>
>>>>   begin <some statements>
>>>>   exception <handle exceptions raised in the statements>
>>>>   end;
>>>>
>>>>Of course, in this proposal the declaration-exception handler would 
>>>>not have access to the declared variables.
>>>
>>>But then, for regularity sake, you would need to add exception handling to
>>>all declarative parts:
>>
>>And why not?
> 
> 
> Because that would make the margin between declarative and imperative more
> fuzzy than it already is.

That is a philosophical reason, and I might even agree with it, but 
it is not a technical problem.

>>>package A is
>>>    <some declarations>
>>>exception
>>>    <handling elaboration problems of A, HOW?>  (:-))
>>>end A;
>>
>>It seems, from your smiley, that you feel that such a structure 
>>would be somehow impossible. I don't see why; the exception handler 
>>could execute any sort of non-erroneous code that could be executed 
>>in any subprogram called as part of the declarations in package A. 
>>For example, it could set some flag in another package to inform 
>>the application that package A cannot be used because its 
>>elaboration failed. If the application uses run-time elaboration 
>>checks, it could even continue executing, as long as it does not 
>>try to use anything in A. I admit that this might need an extended 
>>form of run-time elaboration checks.
> 
> 
> There are two models of exception handling:
> 
> 1. Handle and continue
> 2. Wind-up then handle
> 
> The first was used by PL/1, I cannot tell if it still has it. The second is
> Ada's model. It is sufficiently simpler (no upward closures etc) and also
> more general, because it allows continuation without fixing.

Yes. And I like the Ada approach better.

> Fixing a failed declaration would be the first model. I don't see how this
> could be made, because the exception handler cannot see failed stuff. Which
> is because it is still the second model... They don't live together.

I agree that an exception handler in a package declaration could 
not do anything to recover or repair the failed elaboration (unless 
the package declaration is nested in a subprogram, of course, so 
that the subprogram may be called again with better success).

But such an exception handler could still do something useful, for 
example by logging the problem, invoking some "safing" actions, 
etc., as long as these actions do not depend on the package that 
failed its elaboration.

> For the second model, it is unclear what will be the status of failed A?

The Ada run-time semantics already has a concept of something (eg. 
a subprogram) that is not "yet" elaborated, and can potentially be 
invoked before it is elaborated, triggering a run-time elaboration 
check and possible raising of Program_Error. A package with a 
failed elaboration could be in a similar state.

Note again that I'm not proposing that exception handlers should be 
allowed in package declarations, just exploring the theoretical 
possibility.

> Say, B with-es A and A has failed. That means that B should also fail.

Sure, why not. If A's elaboration fails, all subsystems depending 
on A should be unusable. I think some distinction between failing 
package declarations and failing package bodies could be used to 
contain the spreading of the failure.

>    -- I still cannot handle A's failure here!

I agree that an application could not *recover* from failures in 
package elaboration. But the application could possibly fail more 
gracefully, perhaps even continue operating in a degraded mode.

> It seems that declarations could not be fixed in the second model.

Only in the (unusual) case where a package is nested in a callable 
entity. If the package elaboration fails on one call, the exception 
handlers could take some action that makes the next call succeed 
better. In theory.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: About String

[Chris Moore]

> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:
> 
>> That said, I admit that I, too, have made this mistake once or 
>> twice. But not lately.

Me too.  I think it's one of those mistakes that sticks in the mind.

Dmitry A. Kazakov wrote:

> But then, for regularity sake, you would need to add exception handling to
> all declarative parts:
> 
> package A is
>     <some declarations>
> exception
>     <handling elaboration problems of A, HOW?>  (:-))
> end A;
> 

It might make tracing elaboration errors easier.  :)

Barnes says "... in any handler we are assured that all declarations of 
the unit were successfully elaborated and so there's no risk of 
referring to something that does not exist."  That's sensible but it 
does mean the compiler has to undo memory allocations if they occur in a 
declaration and a subsequent declaration raises an exception.

Chris

Re: About String

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Chris Moore wrote:
>> I have to say this is an entirely non-intuitive "feature" of the language.
>
> I beg to differ. The program should be read as
>
>     declare <some variables>
>     begin <do something with those variables> end;
>
> The exception handler is within the "begin..end" block, not on the
> "declare".

Sure, that's right, but the syntax doesn't make it clear.
We have ample proof that this syntax is confusing:
More than one person in this thread has admitted to
being confused -- QED.  ;-)

I think it was a mistake to attach exception handlers
to declare blocks and procedures and so forth.  Instead,
there should be a single statement for handling exceptions,
as in Java and other languages.  Something like:

    handle
        ... statements ...
    exception
        when ... =>
            ...
    end;

>... (Indenting the "begin..exception..end" structure one level
> beyond the "declare" would make this more visible, but is not common
> practice.)

And it violates the recommended indentation defined by the RM.

Anyway, surely "end" belongs at the same column as "declare"
or "procedure" or whatever it's ending.

> I wonder if it would be a good idea for Ada to allow an exception
> handler also in the "declare" part, as follows:

That goes in the opposite direction I suggested above.
I think it would add confusion.

- Bob

Re: About String

[Sebastien Morand]

> I meant to say
> 
>    procedure Patati_Patata is
>    begin
>       begin
>          declare
>             S : String := A_Function_Raising_Constraint_Error;
>          begin
>             --  some code
>          end;
>       exception
>          when Constraint_Error =>
>             --  deal with the problem ..
>       end;
>       --  .. and carry on
>    end;

And it's what exactly I don't think pretty nice and easy to maintain. Other 
solution proposed by previous post is to separate the code with nested function:

procedure Patati_Patata is

    function Manage_S return String;

    function Manage_S return String is
    begin
       declare
          S : String := A_Function_Raising_Constraint_Error;
       begin
          --  some code
          return S;
       end;
    exception
       when Constraint_Error =>
          --  deal with the problem ..
          return ""; --  Or something else to manage the error but something 
must be returned to be consistent
    end;

    S: String := Manage_S;

begin
    --  .. and carry on
end;

I think it's a better way especially because:
1) You can put away the nested function (for instance as a private package function)
2) You can reuse the function
3) You string are constant most of time (meaning: "S: constant String := Manage_S;")

The only disadvantage for me is that you write a lot little function if you use 
a lot of string (and frankly, you always do in high level application).

I wonder too if there is a nice way to manipulate string using access type. I 
don't choose to try this way because I think it's the better way to introduce 
some memory link.

Sebastien

Re: About String

[Maciej Sobczak]

On 8 Cze, 20:32, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> I think it was a mistake to attach exception handlers
> to declare blocks and procedures and so forth.  Instead,
> there should be a single statement for handling exceptions,
> as in Java and other languages.  Something like:
>
>     handle
>         ... statements ...
>     exception
>         when ... =>
>             ...
>     end;

You did not state it explicitly, but I presume that you allow mixing
declarations with executable code ("as in Java and other languages")?
After all, with the possibility to initialize the new variable with
arbitrarily complex expression (including function call), this is
already the case and the whole declare-begin-end block is just
reflecting some artificial separation.

Get rid of this artificial separation and the problem of exceptions
will be solved.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: About String

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> You did not state it explicitly, but I presume that you allow mixing
> declarations with executable code ("as in Java and other languages")?

Yes, if I ran the circus, I would allow that.  I really find it annoying
that I have to add 3 useless lines of code (declare/begin/end) and an
extra level of indentation, when all I wanted to do was declare
a very-local object.

I also find it annoying that I can't add a statement at the beginning of
a procedure, without moving everything into a local block.  E.g. I have:

    procedure P (X : Integer) is
        Local : constant String := ...;
    begin
        ...

and I want add:

    if X = 0 then
        raise Blah;
    end if;

and I want that to come first.

> After all, with the possibility to initialize the new variable with
> arbitrarily complex expression (including function call), this is
> already the case and the whole declare-begin-end block is just
> reflecting some artificial separation.

I agree.  I suppose it comes from Pascal, where declarations and
executable code are completely separated.  It makes no sense in
Ada, where declarations are just as executable as statements.

- Bob

Re: About String

[Dmitry A. Kazakov]

On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:

> Maciej Sobczak <see.my.homepage@gmail.com> writes:
> 
>> After all, with the possibility to initialize the new variable with
>> arbitrarily complex expression (including function call), this is
>> already the case and the whole declare-begin-end block is just
>> reflecting some artificial separation.
> 
> I agree.  I suppose it comes from Pascal, where declarations and
> executable code are completely separated.  It makes no sense in
> Ada, where declarations are just as executable as statements.

I disagree. I think it does make sense because it clearly defines the scope
of the declared variable. Expression (result) /= named object. And
reversely, if you don't need the variable, you are free to put expressions
anywhere outside the declaration part.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Dmitry A. Kazakov]

On Sun, 08 Jun 2008 20:17:33 +0300, Niklas Holsti wrote:

> I agree that exception contracts would work in this example. Ok, 
> exception contracts would reveal some -- perhaps most -- of these 
> errors at compile time, but not all.

Nothing can reveal all errors.

But errors in exceptions became painful in Ada. I permanently run into the
stuff, like when an unhandled exception winds up controlled objects,
causing secondary exceptions in Finalizes (which may not happen if the
primary exception were handled). It is very difficult to trace back.

[...]
> I agree that an application could not *recover* from failures in 
> package elaboration. But the application could possibly fail more 
> gracefully, perhaps even continue operating in a degraded mode.

I think that partitions could be a better candidate for such things.

Maybe it is a "philosophy" again, but to me failed declarations is a
correctness problem, rather than an exceptional state. As such it should
not be handled inside itself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
> 
>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>
>>> After all, with the possibility to initialize the new variable with
>>> arbitrarily complex expression (including function call), this is
>>> already the case and the whole declare-begin-end block is just
>>> reflecting some artificial separation.
>> I agree.  I suppose it comes from Pascal, where declarations and
>> executable code are completely separated.  It makes no sense in
>> Ada, where declarations are just as executable as statements.
> 
> I disagree. I think it does make sense because it clearly defines the scope
> of the declared variable.

Still, a somewhat *new* kind kind of handling exceptions in single
declarations looks interesting?

Given linear order of elaboration in declarative parts,
and thus the possibility of sequencing initialization
of local variables:

   procedure P is
      declare
         X1: constant T;  -- like Java final
      begin
         X1 := New_T(...);  -- may raise CE
      exception
         when Constraint_Error =>
             X1 := Fallback_T;  -- better than Java final
      end;
      X2: D := New_D(X1, ...);  -- safely refer to X1
   begin
      ...
   end P;

Re: About String

[Dmitry A. Kazakov]

On Mon, 09 Jun 2008 11:43:36 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:

>> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
>> 
>>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>>
>>>> After all, with the possibility to initialize the new variable with
>>>> arbitrarily complex expression (including function call), this is
>>>> already the case and the whole declare-begin-end block is just
>>>> reflecting some artificial separation.

>>> I agree.  I suppose it comes from Pascal, where declarations and
>>> executable code are completely separated.  It makes no sense in
>>> Ada, where declarations are just as executable as statements.

>> I disagree. I think it does make sense because it clearly defines the scope
>> of the declared variable.
 
> Still, a somewhat *new* kind kind of handling exceptions in single
> declarations looks interesting?

> Given linear order of elaboration in declarative parts,
> and thus the possibility of sequencing initialization
> of local variables:
> 
>    procedure P is
>       declare
>          X1: constant T;  -- like Java final
>       begin
>          X1 := New_T(...);  -- may raise CE
>       exception
>          when Constraint_Error =>
>              X1 := Fallback_T;  -- better than Java final
>       end;
>       X2: D := New_D(X1, ...);  -- safely refer to X1
>    begin
>       ...
>    end P;

Huh, if you want closures, just say so. There is no need to break proven
language concepts in order to have desired effect:

procedure P is
    X1: constant T := -- Here anonymous function literal begins
       function return T is
       begin
            return New_T (...);  -- may raise CE
       exception
          when Constraint_Error =>
              return Fallback_T;  -- better than Java final
       end;
   X2: D := New_D (X1, ...);  -- safely refer to X1
begin
   ...
end P;

Note, no magic stuff, no exception handlers in declarations, just a simple
thing, which Ada should have had from the day one: functional types and
literals of.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Sébastien Morand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dmitry A. Kazakov a �crit :
> On Mon, 09 Jun 2008 11:43:36 +0200, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov schrieb:
> 
>>> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
>>>
>>>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>>>
>>>>> After all, with the possibility to initialize the new variable with
>>>>> arbitrarily complex expression (including function call), this is
>>>>> already the case and the whole declare-begin-end block is just
>>>>> reflecting some artificial separation.
> 
>>>> I agree.  I suppose it comes from Pascal, where declarations and
>>>> executable code are completely separated.  It makes no sense in
>>>> Ada, where declarations are just as executable as statements.
> 
>>> I disagree. I think it does make sense because it clearly defines the scope
>>> of the declared variable.
>  
>> Still, a somewhat *new* kind kind of handling exceptions in single
>> declarations looks interesting?
> 
>> Given linear order of elaboration in declarative parts,
>> and thus the possibility of sequencing initialization
>> of local variables:
>>
>>    procedure P is
>>       declare
>>          X1: constant T;  -- like Java final
>>       begin
>>          X1 := New_T(...);  -- may raise CE
>>       exception
>>          when Constraint_Error =>
>>              X1 := Fallback_T;  -- better than Java final
>>       end;
>>       X2: D := New_D(X1, ...);  -- safely refer to X1
>>    begin
>>       ...
>>    end P;
> 
> Huh, if you want closures, just say so. There is no need to break proven
> language concepts in order to have desired effect:
> 
> procedure P is
>     X1: constant T := -- Here anonymous function literal begins
>        function return T is
>        begin
>             return New_T (...);  -- may raise CE
>        exception
>           when Constraint_Error =>
>               return Fallback_T;  -- better than Java final
>        end;
>    X2: D := New_D (X1, ...);  -- safely refer to X1
> begin
>    ...
> end P;
> 
> Note, no magic stuff, no exception handlers in declarations, just a simple
> thing, which Ada should have had from the day one: functional types and
> literals of.

You can do that but not in an anonymous way, so what's the point? I
think it not a good practive to use anonymous function or procedure, it
makes hard to read code (and it's one of the feature of ada: easy to read)

I prefer this kind of writing:
procedure P is

   function Init_T return T;

   function Init_T return T is
   begin
       return New_T (...);  -- may raise CE
   exception
     when Constraint_Error =>
        return Fallback_T;  -- better than Java final
   end;

   X1: constant T := Init_T; -- Here anonymous function literal begins
   X2: D := New_D (X1, ...);  -- safely refer to X1

begin
   ...
end P;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFITQkK+zV9xm4PlDQRAnhxAJ9FKGI7aVenIlDrrnsl3LHJE42FJQCfV9lc
Vvl0CozDP7p/Ah44Ivnz4G8=
=bdGO
-----END PGP SIGNATURE-----

Re: About String

[Georg Bauhaus]

Robert A Duff schrieb:
> Maciej Sobczak <see.my.homepage@gmail.com> writes:
> 
>> You did not state it explicitly, but I presume that you allow mixing
>> declarations with executable code ("as in Java and other languages")?
> 
> Yes, if I ran the circus, I would allow that.  I really find it annoying
> that I have to add 3 useless lines of code (declare/begin/end) and an
> extra level of indentation, when all I wanted to do was declare
> a very-local object.

I find it annoying when I have to search other people's
procedures for variables. A typical sequence of statements is
sprinkled with declarations (Java, C, Perl, ...) and no oher
indication of the newly introduced variables other than
two identifiers before "=" or ";".

As Dmitry says, there is an *implicit* scope only.
When I'm up the wall I speculate whether this viewpoint on language
use is driven by a desire to achieve income by obfuscation?
The tempting quick hack?

To me,  ad hoc variables between statements and Java classes fully
named in source but without "import" at the head of the source file
are similar in character.

The good news is: computers can help us with getting the
necessary "paper work" (declare block etc.) done; use a
good editor.

Re: About String

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>> Given linear order of elaboration in declarative parts,
>> and thus the possibility of sequencing initialization
>> of local variables:
>>
>>    procedure P is
>>       declare
>>          X1: constant T;  -- like Java final
>>       begin
>>          X1 := New_T(...);  -- may raise CE
>>       exception
>>          when Constraint_Error =>
>>              X1 := Fallback_T;  -- better than Java final
>>       end;
>>       X2: D := New_D(X1, ...);  -- safely refer to X1
>>    begin
>>       ...
>>    end P;
> 
> Huh, if you want closures, just say so. There is no need to break proven
> language concepts in order to have desired effect:

I should have said that the scope of X1 extends beyond
the declare block (which I had stupidly chosen as key words).

> procedure P is
>     X1: constant T := -- Here anonymous function literal begins
>        function return T is
>        begin
>             return New_T (...);  -- may raise CE
>        exception
>           when Constraint_Error =>
>               return Fallback_T;  -- better than Java final
>        end;
>    X2: D := New_D (X1, ...);  -- safely refer to X1
> begin
>    ...
> end P;


Why closures? I was about to mention nesting, which
solves this issue in Ada 95 and Ada:

procedure P is
    function Safe_T return T is
    begin
       return New_T (...);  -- may raise CE
    exception
       when Constraint_Error =>
          return Fallback_T;  -- better than Java final
    end;
    X1: constant T := Safe_T;

    X2: D := New_D (X1, ...);  -- safely refer to X1
begin
    ...
end P;

In a sense, Safe_T works just like constructors that don't raise.


> Note, no magic stuff, no exception handlers in declarations, just a simple
> thing, which Ada should have had from the day one: functional types and
> literals of.

With the function's full environment?

Re: About String

[Dmitry A. Kazakov]

On Mon, 09 Jun 2008 13:43:21 +0200, Georg Bauhaus wrote:

> Why closures? I was about to mention nesting, which
> solves this issue in Ada 95 and Ada:

[...]

Only to show what the thing is. [Nested function is a closure too.]

> In a sense, Safe_T works just like constructors that don't raise.

Yes, fail-safe declarations do not raise (per definition).

>> Note, no magic stuff, no exception handlers in declarations, just a simple
>> thing, which Ada should have had from the day one: functional types and
>> literals of.
> 
> With the function's full environment?

Just usual stuff where access type (or a formal generic subprogram) is
presently used instead.

Certainly, no upward closures. So all accessibility checks would apply.
I.e. you would not be able to return a local subprogram.[*]

------------
* Unless [which is a another IMO necessary step] the subprograms is
conditionally pure relatively to the result's type scope.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Britt Snodgrass]

On Jun 9, 6:00 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> Robert A Duff schrieb:
>
> > Maciej Sobczak <see.my.homep...@gmail.com> writes:
>
> >> You did not state it explicitly, but I presume that you allow mixing
> >> declarations with executable code ("as in Java and other languages")?
>
> > Yes, if I ran the circus, I would allow that.  I really find it annoying
> > that I have to add 3 useless lines of code (declare/begin/end) and an
> > extra level of indentation, when all I wanted to do was declare
> > a very-local object.
>
> I find it annoying when I have to search other people's
> procedures for variables. A typical sequence of statements is
> sprinkled with declarations (Java, C, Perl, ...) and no oher
> indication of the newly introduced variables other than
> two identifiers before "=" or ";".
>
> As Dmitry says, there is an *implicit* scope only.
> When I'm up the wall I speculate whether this viewpoint on language
> use is driven by a desire to achieve income by obfuscation?
> The tempting quick hack?
>
> To me,  ad hoc variables between statements and Java classes fully
> named in source but without "import" at the head of the source file
> are similar in character.
>
> The good news is: computers can help us with getting the
> necessary "paper work" (declare block etc.) done; use a
> good editor.

I very much agree. The requirement for an explicit declaritive region
is a very good thing for reasons of readability and maintainability.
If variables could be declared anywhere in a procedure then it really
would be a circus.

- Britt

Re: About String

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
>
>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>> 
>>> After all, with the possibility to initialize the new variable with
>>> arbitrarily complex expression (including function call), this is
>>> already the case and the whole declare-begin-end block is just
>>> reflecting some artificial separation.
>> 
>> I agree.  I suppose it comes from Pascal, where declarations and
>> executable code are completely separated.  It makes no sense in
>> Ada, where declarations are just as executable as statements.
>
> I disagree. I think it does make sense because it clearly defines the scope
> of the declared variable. Expression (result) /= named object. And
> reversely, if you don't need the variable, you are free to put expressions
> anywhere outside the declaration part.

If Ada allowed:

    for I in A'Range loop
        X : constant Character := F(A(I)); -- Not Ada!
        Do_Something(X);
    end loop;

the scope of X is clear -- it's the entire loop body.

    for I in A'Range loop
        declare
            X : constant Character := F(A(I));
        begin
            Do_Something(X);
        end;
    end loop;

does not clarify (in my opinion).  It just adds noise.

You could still say:

    for I in A'Range loop
        begin
            X : constant Character := F(A(I)); -- Not Ada!
            Do_Something(X);
        end;
        Do_Something_Else;
    end loop;

in my circus, if you want to further limit the scope of X
(to smaller than the whole loop body).

- Bob

Re: About String

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Robert A Duff schrieb:
>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>
>>> You did not state it explicitly, but I presume that you allow mixing
>>> declarations with executable code ("as in Java and other languages")?
>> Yes, if I ran the circus, I would allow that.  I really find it
>> annoying
>> that I have to add 3 useless lines of code (declare/begin/end) and an
>> extra level of indentation, when all I wanted to do was declare
>> a very-local object.
>
> I find it annoying when I have to search other people's
> procedures for variables. A typical sequence of statements is
> sprinkled with declarations (Java, C, Perl, ...) and no oher
> indication of the newly introduced variables other than
> two identifiers before "=" or ";".

I suppose it's a matter of taste, at least in part.

But the situation in C-style languages is different -- declarations
don't stand out very well.  In Ada, the declaration syntax is clear
enough without adding "declare/begin/end".

Besides, even with "declare/begin/end", you still have to search all
over the place to find declarations -- they can be in various packages,
and in any outer block, procedure, etc.

> As Dmitry says, there is an *implicit* scope only.
> When I'm up the wall I speculate whether this viewpoint on language
> use is driven by a desire to achieve income by obfuscation?
> The tempting quick hack?

Not at all.  IMHO, "declare/begin/end" obfuscates, by pretending that
the stuff between declare and begin is just declarations, no executable
code.

> To me,  ad hoc variables between statements and Java classes fully
> named in source but without "import" at the head of the source file
> are similar in character.

They seem completely different, to me.  I agree with you that importing
without saying so up front is not good.

> The good news is: computers can help us with getting the
> necessary "paper work" (declare block etc.) done; use a
> good editor.

Sure, I do use a good editor.  That's not the point -- I'm not
complaining about how much work it is to type in "declare/begin/end" --
I'm complaining about how much work it is to _read_ that extra clutter.
The blocks of code we're talking about are often just 2 or 3 lines
of code, so adding several nested declare blocks can easily double
the size of the procedure.

- Bob

Re: About String

[Robert A Duff]

Britt Snodgrass <britt.snodgrass@gmail.com> writes:

> I very much agree. The requirement for an explicit declaritive region
> is a very good thing for reasons of readability and maintainability.
> If variables could be declared anywhere in a procedure then it really
> would be a circus.

But you have not explained why you think declare blocks aid readability
and maintainability.  I don't think they do.  Is it just a matter of
taste, or a matter of what one is used to?

- Bob

Re: About String

[Dmitry A. Kazakov]

On Sun, 15 Jun 2008 15:38:08 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
>>
>>> I agree.  I suppose it comes from Pascal, where declarations and
>>> executable code are completely separated.  It makes no sense in
>>> Ada, where declarations are just as executable as statements.
>>
>> I disagree. I think it does make sense because it clearly defines the scope
>> of the declared variable. Expression (result) /= named object. And
>> reversely, if you don't need the variable, you are free to put expressions
>> anywhere outside the declaration part.
> 
> If Ada allowed:
> 
>     for I in A'Range loop
>         X : constant Character := F(A(I)); -- Not Ada!
>         Do_Something(X);
>     end loop;
>
> the scope of X is clear -- it's the entire loop body.

No, then it should better be something like:

   for I in A'Range;
        X : constant Character := F(A(I)); -- Not Ada!
   loop
      Do_Something(X);
   end loop;

The declarative part of a loop is between "for" and "loop."

However I find nested declare/begin/end more readable because it clearly
disambiguates between the scope of the loop and the scope of one iteration
of.

> You could still say:
> 
>     for I in A'Range loop
>         begin
>             X : constant Character := F(A(I)); -- Not Ada!
>             Do_Something(X);
>         end;
>         Do_Something_Else;
>     end loop;

But what would happen if I said:

   begin
      raise Foo_Error;
      X : constant Character := F(A(I)); -- Not Ada!
      Do_Something (X);
   exception
      when Foo_Error =>
         Do_Something_Interesting (X);
   end;

---------------
What I miss is things like:

procedure Foo (X : T'Class) is
begin
   case X is
      when S_X : S'Class =>
          Do_S_Method (S_X);
      when others =>
          Do_Something_Else;
   end case;
end Foo;

procedure Bar (Ptr : access T'Class) is
begin
   case Ptr is
      when Ref : not null access T =>
          Ref.Foo; -- No more checks
      when others =>
          null;
   end case;
end Bar;

case I is
   when Checked_I : A'Range =>
      ... A (Checked_I) ... -- No range checks
   ...
end case;

case L - 123 is
   when Sum : Positive =>
       -- Sum = L - 123 and it is positive
       ...
   when Sum : Integer =>
       -- Sum = L - 123 and it is not positive
      ...
   when others =>
       -- It would overflow, but no exception was propagated
      ...
end case;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Jun 2008 15:38:08 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sun, 08 Jun 2008 17:19:11 -0400, Robert A Duff wrote:
>>>
>>>> I agree.  I suppose it comes from Pascal, where declarations and
>>>> executable code are completely separated.  It makes no sense in
>>>> Ada, where declarations are just as executable as statements.
>>>
>>> I disagree. I think it does make sense because it clearly defines the scope
>>> of the declared variable. Expression (result) /= named object. And
>>> reversely, if you don't need the variable, you are free to put expressions
>>> anywhere outside the declaration part.
>> 
>> If Ada allowed:
>> 
>>     for I in A'Range loop
>>         X : constant Character := F(A(I)); -- Not Ada!
>>         Do_Something(X);
>>     end loop;
>>
>> the scope of X is clear -- it's the entire loop body.
>
> No, then it should better be something like:
>
>    for I in A'Range;
>         X : constant Character := F(A(I)); -- Not Ada!
>    loop
>       Do_Something(X);
>    end loop;
>
> The declarative part of a loop is between "for" and "loop."

I don't see why a loop needs a declarative part.
My idea is that every statement list is a scope.

> However I find nested declare/begin/end more readable because it clearly
> disambiguates between the scope of the loop and the scope of one iteration
> of.

I don't get it.  You declare something inside a loop body, or the 'then'
part of an 'if' -- it's local to that.

>> You could still say:
>> 
>>     for I in A'Range loop
>>         begin
>>             X : constant Character := F(A(I)); -- Not Ada!
>>             Do_Something(X);
>>         end;
>>         Do_Something_Else;
>>     end loop;
>
> But what would happen if I said:
>
>    begin
>       raise Foo_Error;
>       X : constant Character := F(A(I)); -- Not Ada!
>       Do_Something (X);
>    exception
>       when Foo_Error =>
>          Do_Something_Interesting (X);
>    end;

As I said earlier, exception-handler regions deserve their own syntax,
not connected with declaration blocks.

> ---------------
> What I miss is things like:

Not sure how these are related to local decls...

> procedure Foo (X : T'Class) is
> begin
>    case X is
>       when S_X : S'Class =>
>           Do_S_Method (S_X);
>       when others =>
>           Do_Something_Else;
>    end case;
> end Foo;
>
> procedure Bar (Ptr : access T'Class) is
> begin
>    case Ptr is
>       when Ref : not null access T =>
>           Ref.Foo; -- No more checks
>       when others =>
>           null;
>    end case;
> end Bar;
>
> case I is
>    when Checked_I : A'Range =>
>       ... A (Checked_I) ... -- No range checks
>    ...
> end case;
>
> case L - 123 is
>    when Sum : Positive =>
>        -- Sum = L - 123 and it is positive
>        ...
>    when Sum : Integer =>
>        -- Sum = L - 123 and it is not positive
>       ...
>    when others =>
>        -- It would overflow, but no exception was propagated
>       ...
> end case;

- Bob

Re: About String

[Dmitry A. Kazakov]

On Sun, 15 Jun 2008 18:06:00 -0400, Robert A Duff wrote:

> I don't see why a loop needs a declarative part.
> My idea is that every statement list is a scope.

What is so special in statement lists? Pushing this idea further, we should
also conclude that any sequence of expressions is a scope. For example, an
aggregate:

String'(X : constant Character := F(A(I)), 1 => X, 2 => 'a', 3 => X);

a function call etc.

[ That might be useful to overcome some silly limitations on discriminants:

type T (S : Storage_Count) is record
-- Buffer : Storage_Elements_Array (0..S-1);  -- This would be illegal, so
   Buffer : Storage_Elements_Array
      (Last : constant Storage_Offset := S-1, 0..Last);
end record; ]

>> However I find nested declare/begin/end more readable because it clearly
>> disambiguates between the scope of the loop and the scope of one iteration
>> of.
> 
> I don't get it.  You declare something inside a loop body, or the 'then'
> part of an 'if' -- it's local to that.

Local in which sense? There are statical nesting and dynamic execution of
the loop body upon iterations. It is not obvious (rather counterintuitive)
that declarations have to be "executed." To me the purpose of Ada's
"declare" was merely in conversion of "elaboration" to "execution."

>> But what would happen if I said:
>>
>>    begin
>>       raise Foo_Error;
>>       X : constant Character := F(A(I)); -- Not Ada!
>>       Do_Something (X);
>>    exception
>>       when Foo_Error =>
>>          Do_Something_Interesting (X);
>>    end;

> As I said earlier, exception-handler regions deserve their own syntax,
> not connected with declaration blocks.

So an exception handler attached to the statement list will see nothing
from the scope of the list? I.e. everything in the list will be wound up
before the handler gets fired. Then you would need additional nesting if
you wished to handle exceptions from that list. Here we go:

   X : constant ...;
   Y : constant ...;
   begin
      Do_Something (X, Y);
   exception
      when Foo_Error =>
          Do_Something_Interesting (X, Y);
   end;

What is the gain? Just add "declare" in front of this and it becomes legal
Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Jun 2008 18:06:00 -0400, Robert A Duff wrote:
>
>> I don't see why a loop needs a declarative part.
>> My idea is that every statement list is a scope.
>
> What is so special in statement lists? Pushing this idea further, we should
> also conclude that any sequence of expressions is a scope. For example, an
> aggregate:
>
> String'(X : constant Character := F(A(I)), 1 => X, 2 => 'a', 3 => X);
>
> a function call etc.

Well, I suppose something like that could work, but it seems like it
would be confusing -- how many components are there, which pieces of
text belong to which components (or which parameters, in the function
call case)?

> [ That might be useful to overcome some silly limitations on discriminants:
>
> type T (S : Storage_Count) is record
> -- Buffer : Storage_Elements_Array (0..S-1);  -- This would be illegal, so
>    Buffer : Storage_Elements_Array
>       (Last : constant Storage_Offset := S-1, 0..Last);
> end record; ]

I don't see the point.  Why not just make it legal (the line marked
"This would be illegal").  Rules would be needed about when to evaluate
that expression -- presumably on elaboration of a discriminant
constraint, or an aggregate, or a discriminant default.  I don't think
having a name for Last makes this any easier.

>>> However I find nested declare/begin/end more readable because it clearly
>>> disambiguates between the scope of the loop and the scope of one iteration
>>> of.
>> 
>> I don't get it.  You declare something inside a loop body, or the 'then'
>> part of an 'if' -- it's local to that.
>
> Local in which sense? There are statical nesting and dynamic execution of
> the loop body upon iterations.

The same sense as declare blocks.  That is, in my "circus",
this:

    ... loop
        <decls>
        <statements>
    end loop;

has identical semantics to:

    ... loop
        declare
            <decls>
        begin
            <statements>
        end;
    end loop;

The <decls> are elaborated each time through the loop.
(I can't imagine what _else_ it might mean!)

>...It is not obvious (rather counterintuitive)
> that declarations have to be "executed."

Well, it's a fundamental aspect of Ada, so Ada programmers have to get
used to it, even if they find it counterintuitive at first.

>...To me the purpose of Ada's
> "declare" was merely in conversion of "elaboration" to "execution."
>
>>> But what would happen if I said:
>>>
>>>    begin
>>>       raise Foo_Error;
>>>       X : constant Character := F(A(I)); -- Not Ada!
>>>       Do_Something (X);
>>>    exception
>>>       when Foo_Error =>
>>>          Do_Something_Interesting (X);
>>>    end;
>
>> As I said earlier, exception-handler regions deserve their own syntax,
>> not connected with declaration blocks.
>
> So an exception handler attached to the statement list will see nothing
> from the scope of the list? I.e. everything in the list will be wound up
> before the handler gets fired. Then you would need additional nesting if
> you wished to handle exceptions from that list. Here we go:
>
>    X : constant ...;
>    Y : constant ...;
>    begin
>       Do_Something (X, Y);
>    exception
>       when Foo_Error =>
>           Do_Something_Interesting (X, Y);
>    end;
>
> What is the gain? Just add "declare" in front of this and it becomes legal
> Ada.

That's where this conversation started: If you add "declare" above,
you get confusing syntax -- it looks like the exception handler handles
exceptions during the elab of X and Y, but it does not.
That's why I think it would be better to have a separate
"handle" statement.

- Bob

Re: About String

[Dmitry A. Kazakov]

On Mon, 16 Jun 2008 15:17:15 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 15 Jun 2008 18:06:00 -0400, Robert A Duff wrote:
>>
>>> I don't see why a loop needs a declarative part.
>>> My idea is that every statement list is a scope.
>>
>> What is so special in statement lists? Pushing this idea further, we should
>> also conclude that any sequence of expressions is a scope. For example, an
>> aggregate:
>>
>> String'(X : constant Character := F(A(I)), 1 => X, 2 => 'a', 3 => X);
>>
>> a function call etc.
> 
> Well, I suppose something like that could work, but it seems like it
> would be confusing -- how many components are there, which pieces of
> text belong to which components (or which parameters, in the function
> call case)?

Right, and to me declarations intermixed with statements look similarly
confusing.

>> [ That might be useful to overcome some silly limitations on discriminants:
>>
>> type T (S : Storage_Count) is record
>> -- Buffer : Storage_Elements_Array (0..S-1);  -- This would be illegal, so
>>    Buffer : Storage_Elements_Array
>>       (Last : constant Storage_Offset := S-1, 0..Last);
>> end record; ]
> 
> I don't see the point.  Why not just make it legal (the line marked
> "This would be illegal").

Well, maybe because it wasn't made since 1983? (:-))

> Rules would be needed about when to evaluate
> that expression -- presumably on elaboration of a discriminant
> constraint, or an aggregate, or a discriminant default.  I don't think
> having a name for Last makes this any easier.

It would be a "big" change and with it small ones could also get through...
(:-))

>>>> However I find nested declare/begin/end more readable because it clearly
>>>> disambiguates between the scope of the loop and the scope of one iteration
>>>> of.
>>> 
>>> I don't get it.  You declare something inside a loop body, or the 'then'
>>> part of an 'if' -- it's local to that.
>>
>> Local in which sense? There are statical nesting and dynamic execution of
>> the loop body upon iterations.
> 
> The same sense as declare blocks.  That is, in my "circus",
> this:
> 
>     ... loop
>         <decls>
>         <statements>
>     end loop;
> 
> has identical semantics to:
> 
>     ... loop
>         declare
>             <decls>
>         begin
>             <statements>
>         end;
>     end loop;
> 
> The <decls> are elaborated each time through the loop.
> (I can't imagine what _else_ it might mean!)

An invariant elaborated once for all iterations.

The mental block people like me have is that declarations are neither
statements nor operators. So an iteration does not iterate declarations. Or
better to say, the effect of n iterations is same as one of n+1 iterations.
It is still the same thing pronounced several times: A and A = A.

Making a declaration statement should consequently allow this:

   X : Integer := 1;
   Foo (X);
   X : Float := 2.0;
   Boo (X);

If it is just a statement, why can't I re-execute it?

>>> As I said earlier, exception-handler regions deserve their own syntax,
>>> not connected with declaration blocks.
>>
>> So an exception handler attached to the statement list will see nothing
>> from the scope of the list? I.e. everything in the list will be wound up
>> before the handler gets fired. Then you would need additional nesting if
>> you wished to handle exceptions from that list. Here we go:
>>
>>    X : constant ...;
>>    Y : constant ...;
>>    begin
>>       Do_Something (X, Y);
>>    exception
>>       when Foo_Error =>
>>           Do_Something_Interesting (X, Y);
>>    end;
>>
>> What is the gain? Just add "declare" in front of this and it becomes legal
>> Ada.
> 
> That's where this conversation started: If you add "declare" above,
> you get confusing syntax -- it looks like the exception handler handles
> exceptions during the elab of X and Y, but it does not.
> That's why I think it would be better to have a separate
> "handle" statement.

But "handle" would be still confusing:

handle
   X : constant ...;
   Y : constant ...;
   Do_Something (X, Y);
exception
   when Foo_Error =>
      Do_Something_Interesting (X, Y); -- Illegal
end;

There is no obvious way to mix declarations and statements being able to
handle exceptions from both at the same level.

Maybe I could explain why I don't enjoy the "performance" in another way.
In my eyes declarations have a "declared" persistent effect. It is a name
bound to some new object and the object itself. Statements don't have such
effects.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About String

[Georg Bauhaus]

Robert A Duff wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 15 Jun 2008 18:06:00 -0400, Robert A Duff wrote:
>>
>>> I don't see why a loop needs a declarative part.
>>> My idea is that every statement list is a scope.
>> What is so special in statement lists? Pushing this idea further, we should
>> also conclude that any sequence of expressions is a scope. For example, an
>> aggregate:
>>
>> String'(X : constant Character := F(A(I)), 1 => X, 2 => 'a', 3 => X);
>>
>> a function call etc.
> 
> Well, I suppose something like that could work, but it seems like it
> would be confusing -- how many components are there, which pieces of
> text belong to which components (or which parameters, in the function
> call case)?
> 
>> [ That might be useful to overcome some silly limitations on discriminants:
>>
>> type T (S : Storage_Count) is record
>> -- Buffer : Storage_Elements_Array (0..S-1);  -- This would be illegal, so
>>    Buffer : Storage_Elements_Array
>>       (Last : constant Storage_Offset := S-1, 0..Last);
>> end record; ]
> 
> I don't see the point.  Why not just make it legal (the line marked
> "This would be illegal").  Rules would be needed about when to evaluate
> that expression -- presumably on elaboration of a discriminant
> constraint, or an aggregate, or a discriminant default.  I don't think
> having a name for Last makes this any easier.
> 
>>>> However I find nested declare/begin/end more readable because it clearly
>>>> disambiguates between the scope of the loop and the scope of one iteration
>>>> of.
>>> I don't get it.  You declare something inside a loop body, or the 'then'
>>> part of an 'if' -- it's local to that.
>> Local in which sense? There are statical nesting and dynamic execution of
>> the loop body upon iterations.
> 
> The same sense as declare blocks.  That is, in my "circus",
> this:
> 
>     ... loop
>         <decls>
>         <statements>
>     end loop;


   ... loop
      Get(Buffer(K));
      <decls>   -- depending on Buffer
      <statements>
   end loop;

I guess that in order to maintain the order(?)
SCOPE [DECLS] STATEMENTS END-SCOPE
we would be needing

   ... loop
      Get(Initial(K));
      begin
         <decls>
         <statements>
      end;
   end loop;

> has identical semantics to:
> 
>     ... loop
>         declare
>             <decls>
>         begin
>             <statements>
>         end;
>     end loop;

   ... loop
      Get(Buffer(K));
      declare
         <decls>
      begin
         <statements>
      end;
   end loop;

Compared to the solution above, that would be an exchange
of BEGIN <-> DECLARE and the addition of a BEGIN where there
is nothing between <decls> and <statements> above.

A quick shot at syntax, what impact does this have, if any?
I'm adding a few rather artificial errors, but nevertheless:

   ... scope
      function Foo(N: Integer := K);
      return Value;
   end scope;

   ... scope
      declare
         function Foo(N: Integer := K);
         return Value;
      begin
         null;
      end;
   end scope;

By no more than a gut feeling I'd say that from a syntax
point of view, the omission of explicit declare blocks
adds a few more opportunities for ambiguity: RETURN is
at least not likely introducing a statement in the second
example.

Re: About String

[Robert A Duff]

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:

> A quick shot at syntax, what impact does this have, if any?

It doesn't work at all, syntactically, assuming you want to remain
compatible with Ada.  The whole idea is pure fantasy!  ;-)

- Bob