Ada and "early return" - opinion/practice question

Ada and "early return" - opinion/practice question

[John McCabe]

I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return.

For example, you have a C++ function (pseudo code sort of thing):

<sometype> fn(<some parameters>)
{
    if (<some undesirable condition 1>)
    {
        return <something bad happened 1>;
    }

    if (<some undesirable condition 2>)
    {
        return <something bad 2>;
    }

    if (<some undesirable condition 3>)
    {
        return <something bad 3>;
    }

    // Only get here if everything's good...
    <do some real stuff>
    return <something good>;
}

I've probably mentioned this before, but it's a long time since I used Ada in anger and I don't remember seeing stuff like that when I did use Ada a lot; does anyone write stuff like that in Ada?

When I first learnt to program properly it was using Pascal with, as I remember it, only one return from a function being allowed, so over the years I've mostly looked at positive conditions and indented stuff, pulling the stuff in the middle out into its own procedure or function where appropriate, but you see so many people defending this style in C/C++ that I wonder whether it really is defensible?

Hope this is ok to ask!

John

Re: Ada and "early return" - opinion/practice question

[Dmitry A. Kazakov]

On 2021-03-15 17:46, John McCabe wrote:
> I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return.
> 
> For example, you have a C++ function (pseudo code sort of thing):
> 
> <sometype> fn(<some parameters>)
> {
>      if (<some undesirable condition 1>)
>      {
>          return <something bad happened 1>;
>      }
> 
>      if (<some undesirable condition 2>)
>      {
>          return <something bad 2>;
>      }
> 
>      if (<some undesirable condition 3>)
>      {
>          return <something bad 3>;
>      }
> 
>      // Only get here if everything's good...
>      <do some real stuff>
>      return <something good>;
> }
> 
> I've probably mentioned this before, but it's a long time since I used Ada in anger and I don't remember seeing stuff like that when I did use Ada a lot; does anyone write stuff like that in Ada?

> When I first learnt to program properly it was using Pascal with, as I remember it, only one return from a function being allowed, so over the years I've mostly looked at positive conditions and indented stuff, pulling the stuff in the middle out into its own procedure or function where appropriate, but you see so many people defending this style in C/C++ that I wonder whether it really is defensible?

I see nothing wrong with it. In Ada:

    function fn (<some parameters>) return <sometype> is
    begin
       if <some undesirable condition 1> then
          return <something bad happened 1>;
       elsif <some undesirable condition 2> then
          return <something bad 2>;
       elsif <some undesirable condition 3> then
          return <something bad 3>;
       else --Only get here if everything's good...
          <do some real stuff>
         return <something good>;
    end fn;

P.S. The old mantra of structured programming was one entry, one exit. 
This is why some argued for single return while storing result code in a 
variable. Clearly adding a result variable would reduce readability 
rather than improve it.

P.P.S. One could debate exception vs. return code, but this is another 
story for another day.

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

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On Monday, 15 March 2021 at 17:02:09 UTC, Dmitry A. Kazakov wrote:
> On 2021-03-15 17:46, John McCabe wrote: 
> > I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return. 
> > 
> > For example, you have a C++ function (pseudo code sort of thing): 
<..snip..>

> I see nothing wrong with it. In Ada: 
> 
> function fn (<some parameters>) return <sometype> is 
> begin 
> if <some undesirable condition 1> then
> return <something bad happened 1>;
> elsif <some undesirable condition 2> then 
> return <something bad 2>; 
> elsif <some undesirable condition 3> then 
> return <something bad 3>; 
> else --Only get here if everything's good...
> <do some real stuff> 
> return <something good>;
> end fn; 

Thanks for that Dmitry; the subtlety here is the use of elsif thoughout though, which tends to be skipped in C++ sources. Put that way, what I originally wrote would be:

<sometype> fn(<some parameters>)
{
    if (<some undesirable condition 1>)
    {
        return <something bad happened 1>;
    }
    else if (<some undesirable condition 2>)
    {
        return <something bad 2>;
    }
    else if (<some undesirable condition 3>)
    {
        return <something bad 3>;
    }
    else
    {
        // Only get here if everything's good...
        <do some real stuff>
        return <something good>;
    }
}

I probably wouldn't mind that layout so much, since it makes it clear that the code that's done at the bottom only happens when all the other conditions have been satisfied, and you're less likely to get some random behaviour because of a missing return in the bunch of earlier tests.

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

John McCabe <john@mccabe.org.uk> writes:

> I hope this isn't a FAQ (it's hard to find relevant articles) but can
> someone guide me on the 'normal' treatment in Ada style of what
> appears to be referred to (by C/C++ programmers) as early-return.
>
> For example, you have a C++ function (pseudo code sort of thing):
>
> <sometype> fn(<some parameters>)
> {
>     if (<some undesirable condition 1>)
>     {
>         return <something bad happened 1>;
>     }
>
>     if (<some undesirable condition 2>)
>     {
>         return <something bad 2>;
>     }
>
>     if (<some undesirable condition 3>)
>     {
>         return <something bad 3>;
>     }
>
>     // Only get here if everything's good...
>     <do some real stuff>
>     return <something good>;
> }
>
> I've probably mentioned this before, but it's a long time since I used
> Ada in anger and I don't remember seeing stuff like that when I did
> use Ada a lot; does anyone write stuff like that in Ada?

Sometimes I write code that way, sometimes I have a Result variable that
gets set along the way. The latter mostly when Result is a container of
some sort, and parts of it get set at different points.

I would tend to use an exception for "something bad", but that depends
on the overall design.

There are various maintenance issues on both sides; the summary is
"editing existing code is a pain" :(.

> Hope this is ok to ask!

Sure; there are times when one style is overwhelmingly better (ie
requiring matching end names); this just isn't one of them.

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On Monday, 15 March 2021 at 17:31:33 UTC, Stephen Leake wrote:
> John McCabe <jo...@mccabe.org.uk> writes: 
> 
> > I hope this isn't a FAQ (it's hard to find relevant articles) but can 
> > someone guide me on the 'normal' treatment in Ada style of what 
> > appears to be referred to (by C/C++ programmers) as early-return. 

<..snip..>

> I would tend to use an exception for "something bad", but that depends 
> on the overall design. 

Fair enough.

> There are various maintenance issues on both sides; the summary is 
> "editing existing code is a pain" :(.

Isn't is just; especially the C++ stuff when certain folk aren't quite sure about when not to use templates! In recent months, where I've been learning more and more about the ins and outs of "modern c++", I'm becoming more and more inclined to ditch it and use something where the language designers appear to want to address issues in a way that's consistent and relevant to their users' needs, rather than just fannying around to try to prove how clever they are.

> > Hope this is ok to ask!
> Sure; there are times when one style is overwhelmingly better (ie 
> requiring matching end names); this just isn't one of them. 

Thanks. 

As an aside, is there any way to use this group these days where text layout etc is honoured? Oh for the good old days of usenet!

Cheers
John

Re: Ada and "early return" - opinion/practice question

[Shark8]

On Monday, March 15, 2021 at 10:46:39 AM UTC-6, wrote:
> I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return. 

Exceptions, typically.
Sometimes a return itself, typically in a procedure though.

> For example, you have a C++ function (pseudo code sort of thing): 
> 
> <sometype> fn(<some parameters>) 
> { 
> if (<some undesirable condition 1>) 
> { 
> return <something bad happened 1>; 
> } 
> 
> if (<some undesirable condition 2>) 
> { 
> return <something bad 2>; 
> } 
> 
> if (<some undesirable condition 3>) 
> { 
> return <something bad 3>; 
> } 
> 
> // Only get here if everything's good... 
> <do some real stuff> 
> return <something good>; 
> } 

This is the style for a system that I'm looking at currently, it's interfacing for DLL calls related to some special hardware. My initial method is going to write a thin binding, then "thicken" it up with subtypes and procedures/functions tailored to the system so something like:

Subtype DLL_Return is Interfaces.Unsigned_8; -- Or whatever

Type Temp_Subtype is (A_OK, Out_Of_Range )
  with Size => DLL_Return'Size;

For Temp_Subtype use
( A_OK                => 14,
  Out_Of_Range => 72
);

Function Check_Temp return Temp_Subtype is
  Return_Value : Constant DLL_Return := Do_Temperture_Check;
  Result : Temp_Subtype renames Convert( Return_Value ); -- Convert is instantiation of unchecked_conversion.
Begin
  if DEBUGGING then
    Ada.Text_IO.Put_Line( "Called Check_Temp, got: " & DLL_Return'Image(Return_Value) );
  end if;
  Return Result;
End;

Heck, since the translations are so regular I could probably use Generics to handle leveraging things, meaning the most work would be getting the actual type/values defined.

> I've probably mentioned this before, but it's a long time since I used Ada in anger and I don't remember seeing stuff like that when I did use Ada a lot; does anyone write stuff like that in Ada? 
> 
> When I first learnt to program properly it was using Pascal with, as I remember it, only one return from a function being allowed,
Your memory is correct... for Pascal.
Ada has always allowed multiple return statements in a subprogram, with a "return" in a procedure acting as a "jump to the end, do clean-up".

> so over the years I've mostly looked at positive conditions and indented stuff, pulling the stuff in the middle out into its own procedure or function where appropriate, but you see so many people defending this style in C/C++ that I wonder whether it really is defensible? 

No, it's not defensible... at least IMO.

Re: Ada and "early return" - opinion/practice question

[Shark8]

> 
> As an aside, is there any way to use this group these days where text layout etc is honoured? Oh for the good old days of usenet!

The text-layout used to be honored until the last time that google decided to "upgrade" Google groups.

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On Monday, 15 March 2021 at 18:12:38 UTC, Shark8 wrote:
> On Monday, March 15, 2021 at 10:46:39 AM UTC-6, wrote: 
> > I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return.
> Exceptions, typically. 

<..snip..>

Thanks for that.

> > I've probably mentioned this before, but it's a long time since I used Ada in anger and I don't remember seeing stuff like that when I did use Ada a lot; does anyone write stuff like that in Ada? 
> > 
> > When I first learnt to program properly it was using Pascal with, as I remember it, only one return from a function being allowed,
> Your memory is correct... for Pascal. 
> Ada has always allowed multiple return statements in a subprogram, with a "return" in a procedure acting as a "jump to the end, do clean-up".

Yes; I knew Ada could, but I checked on the Pascal stuff the other day. Things have changed a bit since then (it was, after all, 1983!) but I became quite indoctrinated by that style and it's been hard to shift away from ;-)

> > so over the years I've mostly looked at positive conditions and indented stuff, pulling the stuff in the middle out into its own procedure or function where appropriate, but you see so many people defending this style in C/C++ that I wonder whether it really is defensible?

> No, it's not defensible... at least IMO.

:-)

Re: Ada and "early return" - opinion/practice question

[Jeffrey R. Carter]

On 3/15/21 5:46 PM, John McCabe wrote:
> I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return.
> 
> For example, you have a C++ function (pseudo code sort of thing):
> 
> <sometype> fn(<some parameters>)
> {
>      if (<some undesirable condition 1>)
>      {
>          return <something bad happened 1>;
>      }
> 
>      if (<some undesirable condition 2>)
>      {
>          return <something bad 2>;
>      }
> 
>      if (<some undesirable condition 3>)
>      {
>          return <something bad 3>;
>      }
> 
>      // Only get here if everything's good...
>      <do some real stuff>
>      return <something good>;
> }
> 
> I've probably mentioned this before, but it's a long time since I used Ada in anger and I don't remember seeing stuff like that when I did use Ada a lot; does anyone write stuff like that in Ada?

Other than the use of exceptions rather than a return code, this is a standard 
idiom in Ada. It's much easier to read and understand than the Pascal approach, 
just as a "loop and a a half" is much clearer with an exit than the Pascal approach.

I seem to recall Robert Dewar arguing for this style on here many years ago.

-- 
Jeff Carter
"Choose a data representation that
makes the program simple."
Elements of Programming Style
188

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On Monday, 15 March 2021 at 18:37:04 UTC, Jeffrey R. Carter wrote:
> On 3/15/21 5:46 PM, John McCabe wrote: 
> > I hope this isn't a FAQ (it's hard to find relevant articles) but can someone guide me on the 'normal' treatment in Ada style of what appears to be referred to (by C/C++ programmers) as early-return. 
> > 
> > For example, you have a C++ function (pseudo code sort of thing): 

<..snip..>

> Other than the use of exceptions rather than a return code, this is a standard 
> idiom in Ada. It's much easier to read and understand than the Pascal approach, 
> just as a "loop and a a half" is much clearer with an exit than the Pascal approach. 

Thanks Jeff.

> I seem to recall Robert Dewar arguing for this style on here many years ago. 

From what I remember of Robert (RIP), I suspect he probably argued against it at some point as well, depending on who he was arguing with :-)

Re: Ada and "early return" - opinion/practice question

[Paul Rubin]

John McCabe <john@mccabe.org.uk> writes:
> In recent months, where I've been learning more and more about the ins
> and outs of "modern c++", I'm becoming more and more inclined to ditch
> it and use something where the language designers appear to want to
> address issues in a way that's consistent and relevant to their users'
> needs, rather than just fannying around to try to prove how clever
> they are.

It's a real improvement over old c++ despite the hacky stuff they had to
do to get it to work in the general framework of C++.  The notoriously
clumsy template error messages should improve some with the use of the
c++20 constraints (aka concepts) feature:

https://en.cppreference.com/w/cpp/language/constraints

The book "Effective Modern C++" by Scott Meyer is very good, but is a
few years old (C++17 or so, iirc) and doesn't include this newest stuff.

This also helps:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

Re: Ada and "early return" - opinion/practice question

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> Exceptions, typically.  Sometimes a return itself, typically in a
> procedure though.

This is interesting: I thought in the Java and C++ worlds, using
exceptions to manage normal control flow was frowned on, in part because
the exception mechanism is quite heavyweight.  And in Haskell,
exceptions are considered i/o effects and therefore nasty in pure code
(code with side effects is "impure" and has a special type signature).

Is there wisdom about this in Ada?

Re: Ada and "early return" - opinion/practice question

[Shark8]

On Monday, March 15, 2021 at 1:08:48 PM UTC-6, Paul Rubin wrote:
> Shark8 writes: 
> > Exceptions, typically. Sometimes a return itself, typically in a 
> > procedure though.
> This is interesting: I thought in the Java and C++ worlds, using 
> exceptions to manage normal control flow was frowned on, in part because 
> the exception mechanism is quite heavyweight. And in Haskell, 
> exceptions are considered i/o effects and therefore nasty in pure code 
> (code with side effects is "impure" and has a special type signature). 
> 
> Is there wisdom about this in Ada?

In Ada there's a lot more flexibility and robustness thanks to the type-system.
Take, for example, something like a password type:

Subtype Upper is Character range 'A'..'Z';
Subtype Lower is Character range 'a'..'z';
Subtype Special is Character
  with Static_Predicate => '!'|'@'|'#'|'$'|'%'|'^'|'&'|'*'|'('|')' | '-'|'_'|'+'|'=';

-- a password is a string of length between 7 and 40 with a combination of upper-case, lower-case, and special characters, but at least one from each group.
Type Password is new String
  with Dynamic_Predicate => Password'Length in 7..40
  and (for all C of Password => C in Upper|Lower|Special)
  and (for some C in Password => C in Upper)
  and (for some C in Password => C in Lower)
  and (for some C in Password => C in Special);

Now, given an object (constant, variable, parameter) of "X : Password" and subprogram Do_Something( Input : Password ) a compiler can omit checks on the constraints* for Do_Something( Input => X ), because the object's constraints were already checked. Moreover, because the checking is attached to the type/subtype, you can't forget** to check the validity of the subtype. So having TYPE HANDLE IS NOT NULL ACCESS OBJET'CLASS; means that every single parameter taking HANDLE, or return emitting HANDLE, has embedded into it a check against the null value.



* Kind-of, it's a special case because there are no function-calls here which can change the validity of a password. In the most general case, because it's a Dynamic_Predicate attached to the Password-type, we can't _know_ this is safe. (e.g. a validity-function that alters what's valid based on runtime conditions.)
** There are some things that can get through because the predicate-system uses the same system as ASSERT does, so turning off assertions can break assumptions.

Re: Ada and "early return" - opinion/practice question

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

>> As an aside, is there any way to use this group these days where
>> text layout etc is honoured? Oh for the good old days of usenet!
>
> The text-layout used to be honored until the last time that google
> decided to "upgrade" Google groups.

?

I hadn't noticed a problem

Re: Ada and "early return" - opinion/practice question

[Chris Townley]

On 15/03/2021 20:39, Simon Wright wrote:
> Shark8 <onewingedshark@gmail.com> writes:
> 
>>> As an aside, is there any way to use this group these days where
>>> text layout etc is honoured? Oh for the good old days of usenet!
>>
>> The text-layout used to be honored until the last time that google
>> decided to "upgrade" Google groups.
> 
> ?
> 
> I hadn't noticed a problem
> 

Don't use Google groups! Get a newsfeed and use proper newsreader software.

Personally, I use Eternal September, which is free, and Thunderbird as a 
newsreader. Not perfect but it does...


Chris

Re: Ada and "early return" - opinion/practice question

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:s2o3ud$19im$1@gioia.aioe.org...
> On 2021-03-15 17:46, John McCabe wrote:
...
> I see nothing wrong with it. In Ada:
>
>    function fn (<some parameters>) return <sometype> is
>    begin
>       if <some undesirable condition 1> then
>          return <something bad happened 1>;
>       elsif <some undesirable condition 2> then
>          return <something bad 2>;
>       elsif <some undesirable condition 3> then
>          return <something bad 3>;
>       else --Only get here if everything's good...
>          <do some real stuff>
>         return <something good>;
>    end fn;

I agree with Dmitry; it's not unusual to find this sort of structure in my 
code (usually raising exceptions, though).

With Ada 2012, some of those conditions probably ought to be in the 
precondition, so that people can see what not to do when writing their code. 
That would be:

    function fn (<some parameters>) return <sometype>
       with Pre => (not <some undesirable condition 1>) and then
                          (not <some undesirable condition 2>);

It's not always easy to decide where to draw the line, but a rule of thumb 
that I use is that the precondition should depend only on the parameters 
(not global state) and it should be easy to describe (preferably with a 
simple function call). If those are met, then it probably should be in the 
precondition -- and then the body of the function can assume the 
precondition is true.

                                   Randy.

Re: Ada and "early return" - opinion/practice question

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87im5sutdt.fsf@nightsong.com...
> Shark8 <onewingedshark@gmail.com> writes:
>> Exceptions, typically.  Sometimes a return itself, typically in a
>> procedure though.
>
> This is interesting: I thought in the Java and C++ worlds, using
> exceptions to manage normal control flow was frowned on, ...

We're not talking about "normal control flow" here; we're talking about 
error conditions that typically represent a programming mistake. It's fine 
to use exceptions for that, because they should never occur. When they do, 
you don't really care how expensive they are (again, because they're rare).

If you have a normal case (such as not finding anything in a search), using 
exceptions would generally be considered wrong. Using them would break up 
cases that are logically related.

Ada does take a more flexible approach though. Most Ada programmers would 
rather handle the exception End_Error rather than fill their program with 
tests for end-of-file before every read. I/O is messy enough without putting 
the boundary conditions everywhere (or worse yet, *ignoring* the boundary 
conditions).

So no completely hard-and-fast rule for Ada.

                                          Randy.

Re: Ada and "early return" - opinion/practice question

[Stéphane Rivière]

> Don't use Google groups! Get a newsfeed and use proper newsreader software.

Great advice - Google groups is evil

> Personally, I use Eternal September, which is free, 

same with nntp.aioe.org 563 SSL/TLS - free too

> and Thunderbird as a newsreader. Not perfect but it does...

same

-- 
Be Seeing You
Number Six

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 15/03/2021 17:31, Stephen Leake wrote:
>John McCabe <john@mccabe.org.uk> writes:
>
<..snip..>

>> For example, you have a C++ function (pseudo code sort of thing):
>>
>> <sometype> fn(<some parameters>)
>> {
>>     if (<some undesirable condition 1>)
>>     {
>>         return <something bad happened 1>;
>>     }
>>
>>     if (<some undesirable condition 2>)
>>     {
>>         return <something bad 2>;
>>     }
>>
>>     if (<some undesirable condition 3>)
>>     {
>>         return <something bad 3>;
>>     }
>>
>>     // Only get here if everything's good...
>>     <do some real stuff>
>>     return <something good>;
>> }
>>

<snip>

>I would tend to use an exception for "something bad", but that depends
>on the overall design.

Thinking back on this point, would you do it a style where you try to do
 what needs to be done then handle the exception when it fails? For example,
 in this style

begin
    <try to do a good thing>
exception
    when blah blah
end

Or do you mean, rather than return when the undesirable condition occurs, do
 something like:

if <some undesirable condition 1> then
    raise <some exception 1>
end if;

In other words, does each undesirable condition, when it occurs, throw a
 [potentially] different exception?

Thanks
John

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 15/03/2021 20:56, Chris Townley wrote:
>On 15/03/2021 20:39, Simon Wright wrote:
>> Shark8 <onewingedshark@gmail.com> writes:
>> 
>>>> As an aside, is there any way to use this group these days where
>>>> text layout etc is honoured? Oh for the good old days of usenet!
>>>
>>> The text-layout used to be honored until the last time that google
>>> decided to "upgrade" Google groups.
>> 
>> ?
>> 
>> I hadn't noticed a problem
>> 
>
>Don't use Google groups! Get a newsfeed and use proper newsreader software.
>
>Personally, I use Eternal September, which is free, and Thunderbird as a 
>newsreader. Not perfect but it does...

Thanks for those suggestions. I've now signed up to Eternal September, found
 an
OK (I think) Android app, and will try Emacs' usenet mode, if it's still
 there :-)
Forté Agent used to be my preferred client, but... 

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 15/03/2021 19:05, Paul Rubin wrote:
>John McCabe <john@mccabe.org.uk> writes:
>> In recent months, where I've been learning more and more about the ins
>> and outs of "modern c++", I'm becoming more and more inclined to ditch
>> it and use something where the language designers appear to want to
>> address issues in a way that's consistent and relevant to their users'
>> needs, rather than just fannying around to try to prove how clever
>> they are.
>
>It's a real improvement over old c++ despite the hacky stuff they had to
>do to get it to work in the general framework of C++.  The notoriously
>clumsy template error messages should improve some with the use of the
>c++20 constraints (aka concepts) feature:
>
>https://en.cppreference.com/w/cpp/language/constraints
>
>The book "Effective Modern C++" by Scott Meyer is very good, but is a
>few years old (C++17 or so, iirc) and doesn't include this newest stuff.
>
>This also helps:
>
>https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

I've been using Modern C++ for 3 and a half years now. Yes, there are some
 improvements, but even many of them seem like, as you say, hacky stuff,
 partly because a lot of the additional functionality is not core language
 changes, they're additions to the standard library (many based on Boost),
 yet Boost remains indispensable (especially if you want to be sure that
 condition_variable::wait_for() will use the steady_clock and not the
 system_clock - depending on the compiler you need to use). 

I almost daily find myself finding some new feature then being disappointed
 because they haven't done the whole job. enum class, e.g. was a hugely
 missed opportunity, and CTAD is great, until you want to use
 std::make_shared with it. There just doesn't seem to be the same rigour in
 C++ updates that was obvious in Ada language changes. 

However, I imagine someone has already discussed all this in depth so I
 don't really want to go over all that stuff. 

-- 
Best Regards

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

John McCabe <john@mccabe.org.uk> writes:

> As an aside, is there any way to use this group these days where text
> layout etc is honoured? Oh for the good old days of usenet!

I'm not quite sure what you mean, but I read this newsgroup in Emacs
using Gnus, via nntp.aioe.org:

(setq gnus-select-method
       '(nntp "nntp.aioe.org")
      )

usenet lives :)

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

John McCabe <"john@nospam.mccabe.org.uk"> writes:

> On 15/03/2021 17:31, Stephen Leake wrote:
>>John McCabe <john@mccabe.org.uk> writes:
>>
> <..snip..>
>
>>> For example, you have a C++ function (pseudo code sort of thing):
>>>
>>> <sometype> fn(<some parameters>)
>>> {
>>>     if (<some undesirable condition 1>)
>>>     {
>>>         return <something bad happened 1>;
>>>     }
>>>
>>>     if (<some undesirable condition 2>)
>>>     {
>>>         return <something bad 2>;
>>>     }
>>>
>>>     if (<some undesirable condition 3>)
>>>     {
>>>         return <something bad 3>;
>>>     }
>>>
>>>     // Only get here if everything's good...
>>>     <do some real stuff>
>>>     return <something good>;
>>> }
>>>
>
> <snip>
>
>>I would tend to use an exception for "something bad", but that depends
>>on the overall design.
>
> Thinking back on this point, would you do it a style where you try to do
> what needs to be done then handle the exception when it fails? For example,
> in this style
>
> begin
>    <try to do a good thing>
> exception
>    when blah blah
> end

No, your example fn returns a status code to the caller for "something
bad", so the Ada fn should raise an exception, and the caller (or some
function up the call chain) should handle it.

> Or do you mean, rather than return when the undesirable condition occurs, do
> something like:
>
> if <some undesirable condition 1> then
>    raise <some exception 1>
> end if;

Yes, but with helpful info in the exception message:

    raise <some exception 1> with "explanation";

For example, if the problem is that some number is out of bounds, the
"explanation" should include both the number and the bounds. And if the
bounds can be adjusted by a user option, the option name.

<rant>
The most frustrating error message ever is from Windows, when a program
is missing some DLL or other file; the error message says:

    the file cannot be found.

_Which_ file???!!! the program knows exactly what file name it is looking
for, and what directories it is looking in; why isn't it telling me?

Sigh.
</rant>

I often spend a lot of effort to improve error messages; they help a lot
when debugging, especially a few years later.

Sometimes I would like to pass data with the exception, as other
languages support, but not often.

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

Paul Rubin <no.email@nospam.invalid> writes:

> Shark8 <onewingedshark@gmail.com> writes:
>> Exceptions, typically.  Sometimes a return itself, typically in a
>> procedure though.
>
> This is interesting: I thought in the Java and C++ worlds, using
> exceptions to manage normal control flow was frowned on, in part because
> the exception mechanism is quite heavyweight.  And in Haskell,
> exceptions are considered i/o effects and therefore nasty in pure code
> (code with side effects is "impure" and has a special type signature).
>
> Is there wisdom about this in Ada?

GNAT has zero-cost exceptions; raising an exception is the same as goto.

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 16/03/2021 09:03, Stephen Leake wrote:
>John McCabe <john@mccabe.org.uk> writes:
>
>> As an aside, is there any way to use this group these days where text
>> layout etc is honoured? Oh for the good old days of usenet!
>
>I'm not quite sure what you mean, but I read this newsgroup in Emacs
>using Gnus, via nntp.aioe.org:
>
>(setq gnus-select-method
>       '(nntp "nntp.aioe.org")
>      )
>
>usenet lives :)

Yay :-) 

-- 
Best Regards

Re: Ada and "early return" - opinion/practice question

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> We're not talking about "normal control flow" here; we're talking about 
> error conditions that typically represent a programming mistake. It's fine 
> to use exceptions for that, because they should never occur. 

Ok, sure, that's the purpose of exceptions.  But the original question
didn't give the impression that was the situation.  It looked more like
a normal error condition, such as unsuccessfully trying to open a
network connection to somewhere.  Handling that condition is normal
control flow rather than recovering from a programming error (network
interruptions are routine situations).

The issue then is not just possible slow performance of exceptions, but
also the added difficulty of understanding what the program is doing
when exceptions are in play.  An exception is in some ways a goto on
steroids.  Without checked exceptions you don't know where the handler
is, and experienced with Java showed checked exceptions are such a pain
that all kinds of special unchecked exceptions ended up being allowed.

Does Ada have checked exceptions?  That basically means any function
that can raise an exception must declare what exceptions it can raise,
and that list is also inherited from anything below it in the call tree.

The Haskell fashion these days is to write functions, when possible,
that never raise exceptions.  For example, the "head" function (which
gives back the first element of a list) raises an exception if its arg
is an empty list.  It is a very basic function in the standard Haskell
library that was once used freely, but now its use is considered
suspect.

I think that Ada has a way of verifying with Spark that a function can
never raise an exception, and that this is an important use of Spark.

Re: Ada and "early return" - opinion/practice question

[Dmitry A. Kazakov]

On 2021-03-16 09:24, John McCabe wrote:
> On 15/03/2021 17:31, Stephen Leake wrote:
>> John McCabe <john@mccabe.org.uk> writes:
>>
> <..snip..>
> 
>>> For example, you have a C++ function (pseudo code sort of thing):
>>>
>>> <sometype> fn(<some parameters>)
>>> {
>>>     if (<some undesirable condition 1>)
>>>     {
>>>         return <something bad happened 1>;
>>>     }
>>>
>>>     if (<some undesirable condition 2>)
>>>     {
>>>         return <something bad 2>;
>>>     }
>>>
>>>     if (<some undesirable condition 3>)
>>>     {
>>>         return <something bad 3>;
>>>     }
>>>
>>>     // Only get here if everything's good...
>>>     <do some real stuff>
>>>     return <something good>;
>>> }
>>>
> 
> <snip>
> 
>> I would tend to use an exception for "something bad", but that depends
>> on the overall design.
> 
> Thinking back on this point, would you do it a style where you try to do
> what needs to be done then handle the exception when it fails? For example,
> in this style
> 
> begin
>     <try to do a good thing>
> exception
>     when blah blah
> end
> 
> Or do you mean, rather than return when the undesirable condition 
> occurs, do
> something like:
> 
> if <some undesirable condition 1> then
>     raise <some exception 1>
> end if;
> 
> In other words, does each undesirable condition, when it occurs, throw a
> [potentially] different exception?

It is a difficult choice. One would expect a different exception for 
each case. Unfortunately Ada lacks important features to support that 
design:

1. Exception contracts. If you have many different exceptions it becomes 
increasingly difficult to track them.

2. There is no way to group exceptions in a tree-like or relational 
structure. You cannot name a group and handle its exceptions as whole. 
You have no operations on such groups etc.

A rather pragmatic design is to use a minimal set of exceptions packing 
structured information into the exception message. A quite fragile approach.

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

Re: Ada and "early return" - opinion/practice question

[Dmitry A. Kazakov]

On 2021-03-16 08:17, Randy Brukardt wrote:
> "Paul Rubin" <no.email@nospam.invalid> wrote in message
> news:87im5sutdt.fsf@nightsong.com...
>> Shark8 <onewingedshark@gmail.com> writes:
>>> Exceptions, typically.  Sometimes a return itself, typically in a
>>> procedure though.
>>
>> This is interesting: I thought in the Java and C++ worlds, using
>> exceptions to manage normal control flow was frowned on, ...
> 
> We're not talking about "normal control flow" here; we're talking about
> error conditions that typically represent a programming mistake.

Error conditions cannot be handled, period.

Unless you mean sloppy programming: I do not know what to do if this 
happens, so I drop an exception. But will tell nobody, let them have fun.

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

Re: Ada and "early return" - opinion/practice question

[Jeffrey R. Carter]

On 3/16/21 8:19 AM, Stéphane Rivière wrote:
> 
>> Personally, I use Eternal September, which is free,
> 
> same with nntp.aioe.org 563 SSL/TLS - free too
> 
>> and Thunderbird as a newsreader. Not perfect but it does...
> 
> same

I also use these.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: Ada and "early return" - opinion/practice question

[Jeffrey R. Carter]

On 3/16/21 9:24 AM, John McCabe wrote:
> 
> Thinking back on this point, would you do it a style where you try to do
> what needs to be done then handle the exception when it fails? For example,
> in this style
> 
> begin
>     <try to do a good thing>
> exception
>     when blah blah
> end

That depends on a lot of things. In some cases, Bad_Condition means that 
Do_Good_Things will produce a wrong answer rather than fail, so this construct 
cannot be used.

If Do_Good_Things will raise an exception for every Bad_Condition, then it 
depends on how fine-grained those exceptions are and how helpful you want to be 
to the caller. If a different exception is raised for each Bad_Condition, then 
this is equivalent to explicitly raising an exception for each Bad_Condition. If 
you get the same exception for all, you may reduced to telling your caller that 
there's something wrong with the values supplied.

> Or do you mean, rather than return when the undesirable condition occurs, do
> something like:
> 
> if <some undesirable condition 1> then
>     raise <some exception 1>
> end if;
> 
> In other words, does each undesirable condition, when it occurs, throw a
> [potentially] different exception?

I lean toward using fine-grained exceptions, so I'd probably use a different 
exception for each, and document when each exception is raised, or at least 
provide a different exception msg for each.

On the other hand, these kinds of tests can often become preconditions in Ada 
12, in which case you get a single exception, possibly with a generic msg that 
the precondition failed.

Why would you write "raise <some exception 1>" and then talk about "throwing"?
There's no throwing in Ada. That only happens in error-prone languages.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: Ada and "early return" - opinion/practice question

[Niklas Holsti]

On 2021-03-16 11:16, Stephen Leake wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
> 
>> Shark8 <onewingedshark@gmail.com> writes:
>>> Exceptions, typically.  Sometimes a return itself, typically in a
>>> procedure though.
>>
>> This is interesting: I thought in the Java and C++ worlds, using
>> exceptions to manage normal control flow was frowned on, in part because
>> the exception mechanism is quite heavyweight.  And in Haskell,
>> exceptions are considered i/o effects and therefore nasty in pure code
>> (code with side effects is "impure" and has a special type signature).
>>
>> Is there wisdom about this in Ada?
> 
> GNAT has zero-cost exceptions; raising an exception is the same as goto.


Are you sure about that? As I understand it, for the full-runtime GNAT 
systems, the "zero cost exception handling" means that there is no 
run-time cost to placing an exception handler in a subprogram or block, 
because there is no run-time code to set up such a handler when entering 
the subprogram or block, nor to remove it when leaving the subprogram or 
block.

But there is cost, partly at compile/link time, when the tools set up a 
static mapping from code sections (address ranges) to the exception 
handlers that handle exceptions raised in those parts of the code, and 
partly at run-time when an exception is raised. AIUI raising an 
exception is not a mere goto: at run-time, the code has to use the 
static mapping to locate the applicable handler, while also unwinding 
the call-stack to the corresponding point, and then enter the handler code.

So the GNAT "zero cost" exception system is optimized for having plenty 
of exception handlers in the code, but rarely having to handle 
exceptions during execution, which is as it should be, IMO.

A different zero-cost system is used when GNAT compiles for embedded 
targets with run-times that do not support exception propagation. In 
those cases, one can write only "local" exception handlers. For example, 
the exception handlers in a subprogram can handle only exceptions raised 
in that same subprogram, but not exceptions raised in any callee 
subprograms. Then raising an exception is indeed the same as a goto, 
because the compiler statically knows if there is a local handler, and 
where it is, and no stack unwinding is needed. If there is no local 
exception handler, raising an exception is a "goto" the GNAT last-chance 
handler followed by program termination. But this applies only in these 
restricted run-time environments.

Re: Ada and "early return" - opinion/practice question

[John McCabe]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> John McCabe <"john@nospam.mccabe.org.uk"> writes:
>
>> On 15/03/2021 17:31, Stephen Leake wrote:
>>>John McCabe <john@mccabe.org.uk> writes:
>>>
>> <..snip..>
>>.. <..snip..>

>>>I would tend to use an exception for "something bad", but that depends
>>>on the overall design.

>> Thinking back on this point, would you do it a style where you try to do
>> what needs to be done then handle the exception when it fails? For example,
>> in this style
>>
>> begin
>>    <try to do a good thing>
>> exception
>>    when blah blah
>> end
>
> No, your example fn returns a status code to the caller for "something
> bad", so the Ada fn should raise an exception, and the caller (or some
> function up the call chain) should handle it.

>> Or do you mean, rather than return when the undesirable condition occurs, do
>> something like:

>> if <some undesirable condition 1> then
>>    raise <some exception 1>
>> end if;

> Yes, but with helpful info in the exception message:

>     raise <some exception 1> with "explanation";

That "with" part's new since I regularly used Ada :-)

> For example, if the problem is that some number is out of bounds, the
> "explanation" should include both the number and the bounds. And if the
> bounds can be adjusted by a user option, the option name.

That seems reasonable; similar to C++ where you can "throw
std::logic_error("message");" kind of thing.

Re: Ada and "early return" - opinion/practice question

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Shark8 <onewingedshark@gmail.com> writes:
>
>>> As an aside, is there any way to use this group these days where
>>> text layout etc is honoured? Oh for the good old days of usenet!
>>
>> The text-layout used to be honored until the last time that google
>> decided to "upgrade" Google groups.
>
> ?
>
> I hadn't noticed a problem

What I meant was, I haven't particularly noticed any badly-formatted
posts on here while reading & posting with Emacs via nntp.aioe.org

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

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

> Are you sure about that? As I understand it, for the full-runtime GNAT
> systems, the "zero cost exception handling" means that there is no 
> run-time cost to placing an exception handler in a subprogram or
> block, because there is no run-time code to set up such a handler when
> entering the subprogram or block, nor to remove it when leaving the
> subprogram or block.

right

> But there is cost, partly at compile/link time, when the tools set up
> a static mapping from code sections (address ranges) to the exception 
> handlers that handle exceptions raised in those parts of the code, 

right.

> and partly at run-time when an exception is raised. AIUI raising an
> exception is not a mere goto: at run-time, the code has to use the
> static mapping to locate the applicable handler, while also unwinding
> the call-stack to the corresponding point, and then enter the handler
> code

Yes; it is more like a sequence of "return" than "goto".

It is cheaper at run-time than the previous implemententation of
exceptions, which used set-jmp/long-jmp.

> A different zero-cost system is used when GNAT compiles for embedded
> targets with run-times that do not support exception propagation. In 
> those cases, one can write only "local" exception handlers. For
> example, the exception handlers in a subprogram can handle only
> exceptions raised in that same subprogram, but not exceptions raised
> in any callee subprograms. Then raising an exception is indeed the
> same as a goto, because the compiler statically knows if there is a
> local handler, and where it is, and no stack unwinding is needed. 

I did not know about this one.

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 16/03/2021 20:34, Simon Wright wrote:
>Simon Wright <simon@pushface.org> writes:
>
>> Shark8 <onewingedshark@gmail.com> writes:
>>
>>>> As an aside, is there any way to use this group these days where
>>>> text layout etc is honoured? Oh for the good old days of usenet!
>>>
>>> The text-layout used to be honored until the last time that google
>>> decided to "upgrade" Google groups.
>>
>> ?
>>
>> I hadn't noticed a problem
>
>What I meant was, I haven't particularly noticed any badly-formatted
>posts on here while reading & posting with Emacs via nntp.aioe.org

As a matter of interest, what version of Emacs are you using? I tried Gnus,
 but kept getting messages like "that's a weird message-I'd, do you really
 want to send it"? A search suggested it was some issue with the way emacs
 gets the system name. That was on 27.1 on Windows 10, 64 bit. 

-- 
Best Regards

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 16/03/2021 10:46, Jeffrey R. Carter wrote:
>On 3/16/21 9:24 AM, John McCabe wrote:
>> 

<..snip..>

>Why would you write "raise <some exception 1>" and then talk about "throwing"?
>There's no throwing in Ada. That only happens in error-prone languages.

LOL - give me a break; it's taken me nearly 20 years to get into the habit
 of using 'throw', as the die-hard, never used a decent language, C/C++ lot
 I've worked with over that period have no clue what it is to raise an
 exception! :-) 

-- 
Best Regards

Re: Ada and "early return" - opinion/practice question

[AdaMagica]

> LOL - give me a break; it's taken me nearly 20 years to get into the habit 
> of using 'throw', as the die-hard, never used a decent language, C/C++ lot 
> I've worked with over that period have no clue what it is to raise an 
> exception! :-) 
Praps it's like raising a finger vs. throwing a finger. Sounds like mafia ;-)

Re: Ada and "early return" - opinion/practice question

[Simon Wright]

John McCabe <"john@nospam.mccabe.org.uk"> writes:

> On 16/03/2021 20:34, Simon Wright wrote:
>>Simon Wright <simon@pushface.org> writes:
>>
>>> Shark8 <onewingedshark@gmail.com> writes:
>>>
>>>>> As an aside, is there any way to use this group these days where
>>>>> text layout etc is honoured? Oh for the good old days of usenet!
>>>>
>>>> The text-layout used to be honored until the last time that google
>>>> decided to "upgrade" Google groups.
>>>
>>> ?
>>>
>>> I hadn't noticed a problem
>>
>>What I meant was, I haven't particularly noticed any badly-formatted
>>posts on here while reading & posting with Emacs via nntp.aioe.org
>
> As a matter of interest, what version of Emacs are you using? I tried Gnus,
> but kept getting messages like "that's a weird message-I'd, do you really
> want to send it"? A search suggested it was some issue with the way emacs
> gets the system name. That was on 27.1 on Windows 10, 64 bit. 

GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
Version 10.14.6 (Build 18G95)) of 2020-08-12

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On 17/03/2021 11:43, Simon Wright wrote:
>John McCabe <"john@nospam.mccabe.org.uk"> writes:
>
<..snip..>
>>
>> As a matter of interest, what version of Emacs are you using? I tried Gnus,
>> but kept getting messages like "that's a weird message-I'd, do you really
>> want to send it"? A search suggested it was some issue with the way emacs
>> gets the system name. That was on 27.1 on Windows 10, 64 bit. 
>
>GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
>Version 10.14.6 (Build 18G95)) of 2020-08-12

Interesting; thanks. Maybe it's just a Windows issue. 


-- 
Best Regards
John

Re: Ada and "early return" - opinion/practice question

[Stephen Leake]

John McCabe <"john@nospam.mccabe.org.uk"> writes:

> On 17/03/2021 11:43, Simon Wright wrote:
>>John McCabe <"john@nospam.mccabe.org.uk"> writes:
>>
> <..snip..>
>>>
>>> As a matter of interest, what version of Emacs are you using? I tried Gnus,
>>> but kept getting messages like "that's a weird message-I'd, do you really
>>> want to send it"? A search suggested it was some issue with the way emacs
>>> gets the system name. That was on 27.1 on Windows 10, 64 bit. 
>>
>>GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
>>Version 10.14.6 (Build 18G95)) of 2020-08-12
>
> Interesting; thanks. Maybe it's just a Windows issue. 

I'm using Emacs Gnus on Windows, and have for decades. Currently 
Emacs 27.1, launched from mingw64 shell.

-- 
-- Stephe

Re: Ada and "early return" - opinion/practice question

[John McCabe]

On Thu, 18 Mar 2021 09:27:44 -0700, Stephen Leake wrote:

> John McCabe <"john@nospam.mccabe.org.uk"> writes:
> 
>> On 17/03/2021 11:43, Simon Wright wrote:
>>>John McCabe <"john@nospam.mccabe.org.uk"> writes:
>>>
>> <..snip..>
>>>>
>>>> As a matter of interest, what version of Emacs are you using? I tried
>>>> Gnus,
>>>> but kept getting messages like "that's a weird message-I'd, do you
>>>> really want to send it"? A search suggested it was some issue with
>>>> the way emacs gets the system name. That was on 27.1 on Windows 10,
>>>> 64 bit.
>>>
>>>GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
>>>Version 10.14.6 (Build 18G95)) of 2020-08-12
>>
>> Interesting; thanks. Maybe it's just a Windows issue.
> 
> I'm using Emacs Gnus on Windows, and have for decades. Currently Emacs
> 27.1, launched from mingw64 shell.

Interesting; downloaded or built yourself? This one? "GNU Emacs 27.1 
(build 1, x86_64-w64-mingw32) of 2020-08-21"?

FWIW - it's not really a problem; I've started using pan on Linux, partly 
because there are also issues with blank menus on 27.1 that made it 
harder to get started when there are thousands of key combinations to 
learn :-)

Thanks though
John