stopping a loop iteration without exiting it

stopping a loop iteration without exiting it

[Mehdi Saada]

Is there a way to tell to ignore the remaining of a loop ? Like an exit statement, but instead of quiting the loop, it would go to the next iteration.
Can we do this except with a recursive structure ?

Re: stopping a loop iteration without exiting it

[Lucretia]

On Wednesday, 3 January 2018 16:54:36 UTC, Mehdi Saada  wrote:
> Is there a way to tell to ignore the remaining of a loop ? Like an exit statement, but instead of quiting the loop, it would go to the next iteration.
> Can we do this except with a recursive structure ?

You mean like "continue" in C? No, there's no way in Ada, unless you use a goto which is stupid. Just structure your loop properly.

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:81971548-23c9-4927-a6a8-6f0f1dba896b@googlegroups.com...
> On Wednesday, 3 January 2018 16:54:36 UTC, Mehdi Saada  wrote:
>> Is there a way to tell to ignore the remaining of a loop ? Like an exit 
>> statement, but instead of quiting the loop, it would go to the next 
>> iteration.
>> Can we do this except with a recursive structure ?
>
> You mean like "continue" in C? No, there's no way in Ada, unless you use a 
> goto
> which is stupid. Just structure your loop properly.

A "goto" is *not* stupid in this case. It isn't always sensible to 
restructure a loop to avoid "continue". We looked at adding the feature 
sometime back (it happens hundreds of times in the GNAT source code), but 
the decision was that a goto was good enough. (Especially after the syntax 
change allowing it directly at the end of a loop.) That is:

    loop
      ...
             goto Continue;
      ...
    <<Continue>>
    end loop;

                                  Randy.

Re: stopping a loop iteration without exiting it

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> A "goto" is *not* stupid in this case.

I agree.  There are (rare) cases in Ada when "goto" is the right
solution, and nested "continue" can be one of them.

I've even heard the argument that "Goto CAN always be replaced by
if/while/etc" (proved by Jacopini in the 60's, IIRC), that therefore
"Goto SHOULD always be replaced by if/while/etc".  That "therefore"
is obviously a logical fallacy.

>... It isn't always sensible to 
> restructure a loop to avoid "continue". We looked at adding the feature 
> sometime back (it happens hundreds of times in the GNAT source code), but 
> the decision was that a goto was good enough.

In fact, the goto is BETTER than the continue statement, because the
place where it's jumping to is marked with a label, as in Randy's
example below.  With a "continue", when you see "end loop" (or "}"!)
you have no clue that "something is interesting here -- somebody is
jumping to this place".

Jeff's suggestion (nested 'if' in the loop) is a good one when it works,
but it doesn't work when the "continue" is nested within further control
constructs.

>...(Especially after the syntax 
> change allowing it directly at the end of a loop.) That is:
>
>     loop
>       ...
>              goto Continue;
>       ...
>     <<Continue>>
>     end loop;

And Randy indents the "goto" a lot, to show that it is (perhaps) deeply
nested.  That's exactly when the goto makes good sense.

- Bob

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-04 01:17 , Robert A Duff wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> A "goto" is *not* stupid in this case.
>
> I agree.  There are (rare) cases in Ada when "goto" is the right
> solution, and nested "continue" can be one of them.

But many coding rules frown on "goto" (with good reason, IMO). If 
"continue" is implemented with "goto", either the code-rule-checking 
tools will flag these "gotos" as violations, or the tools must be taught 
to tolerate "gotos" when they are used for "continue".

IMO, if there is a frequent need for a "continue" construct in Ada 
programming, it should just be added to the language, even if this seems 
like shameful imitation of some other, more popular languages.

That said, I don't remember ever having a need for a "continue" in my 
Ada programming, but perhaps this depends on one's design style and 
favourite coding idioms.

> In fact, the goto is BETTER than the continue statement, because the
> place where it's jumping to is marked with a label, ..

If "continue" were added to Ada, of course it should have an optional 
loop-name to mark the loop being continued, as for the current "exit":

     exit Search_Loop when ...;

     continue Search_Loop when ...;

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

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fb680nFc4gpU1@mid.individual.net...
> On 18-01-04 01:17 , Robert A Duff wrote:
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
>>> A "goto" is *not* stupid in this case.
>>
>> I agree.  There are (rare) cases in Ada when "goto" is the right
>> solution, and nested "continue" can be one of them.
>
> But many coding rules frown on "goto" (with good reason, IMO). If 
> "continue" is implemented with "goto", either the code-rule-checking tools 
> will flag these "gotos" as violations, or the tools must be taught to 
> tolerate "gotos" when they are used for "continue".

There is nothing the Standard can do about bad programming management. ;-)

Coding standards that blindly ban features force programs into convuluted 
structures. Which defeat the purpose of the coding standard in the first 
place.

> IMO, if there is a frequent need for a "continue" construct in Ada 
> programming, it should just be added to the language, even if this seems 
> like shameful imitation of some other, more popular languages.

It's not a frequent need, it's just a non-zero need. I find I end up up 
writing such a goto (very roughly) once a year. But a good number of them 
aren't strict continues; there's often something at the bottom of the loop 
after the label.

> That said, I don't remember ever having a need for a "continue" in my Ada 
> programming, but perhaps this depends on one's design style and favourite 
> coding idioms.
>
>> In fact, the goto is BETTER than the continue statement, because the
>> place where it's jumping to is marked with a label, ..
>
> If "continue" were added to Ada, of course it should have an optional 
> loop-name to mark the loop being continued, as for the current "exit":
>
>     exit Search_Loop when ...;
>
>     continue Search_Loop when ...;

I think you miss the point: the fact that there is a goto to the end of the 
loop is marked by a label in this (the "continue") case. "Continue" is NOT 
the usual case (it is rare enough that we decided not to add it because it 
would need a new keyword and inevitably break existing code using the label 
"Continue"), so the presence of the label at the end keys the reader that 
you can get there in other ways then just dropping out of the if statement 
that probably preceeds the "end loop". That's what Bob meant by saying that 
it is "better". (The sort of loop that needs a "continue" is likely to be 
very long.) This is likely the same reason that Ada 83 didn't allow goto to 
a loop name (when one sees a loop name, one ignores it unless you are 
tracing exits).

                                     Randy.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/04/2018 12:17 AM, Robert A Duff wrote:
> 
> Jeff's suggestion (nested 'if' in the loop) is a good one when it works,
> but it doesn't work when the "continue" is nested within further control
> constructs.

I have never seen a real-world situation in which a "continue" was needed. The 
vast majority of times that I've seen where people have claimed they needed it, 
it could be replaced by an "if". The few remaining cases involved very 
convoluted and unreadable code. When it was rethought and simplified, it no 
longer needed a "continue". I would be interested in seeing real-world examples 
where it was needed.

An informative data point is the book /Software Tools/, which presents a whole 
lot of code in Ratfor, which has an equivalent of "continue". Interestingly, it 
is never used.

-- 
Jeff Carter
"Damn it, Jim, I'm an actor, not a doctor."
124

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-04 11:08, Jeffrey R. Carter wrote:
> On 01/04/2018 12:17 AM, Robert A Duff wrote:
>>
>> Jeff's suggestion (nested 'if' in the loop) is a good one when it works,
>> but it doesn't work when the "continue" is nested within further control
>> constructs.
> 
> I have never seen a real-world situation in which a "continue" was 
> needed. The vast majority of times that I've seen where people have 
> claimed they needed it, it could be replaced by an "if".

A typical case is a sequence of chained actions:

loop
    if This then
       Do_This;
       if That then
          Do_That;
          if More then
             Do_More
             if Even_More then
                Do_Even_More
                ...
             end if;
          end if;
       end if;
    end if;
end loop;

This cannot be handled without either:

1. Introducing a break-out exception
2. A Boolean guard/carry variable

Neither 1 nor 2 is really shining.

Now compare it to:

loop
    continue when not This;
    Do_This;
    continue when not That;
    Do_That;
    continue when not More;
    Do_More
    continue when not Even_More;
    Do_Even_More
    ...
end loop;

P.S. What I don't understand is why loop names cannot serve as labels. 
Why this:

loop
    ...
    goto Continue;
    ...
    <<Continue>>
end loop;

Instead of simple:

Process : loop
    ...
    goto Process;
    ...
end loop Process;

P.P.S. When-for-everyone is long overdue:

    goto <label> when <condition>;
    return [<result>] when <condition>;
    raise <exception> [with <message>] when <condition>;

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

Re: stopping a loop iteration without exiting it

[Robert A Duff]

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

> P.P.S. When-for-everyone is long overdue:
>
>    goto <label> when <condition>;
>    return [<result>] when <condition>;
>    raise <exception> [with <message>] when <condition>;

Those were all proposed for Ada 9X.  They were rejected,
IIRC, because they're mere "nice to haves", and the mood
was generally "simplify by removing features".  (Since the
above make the language more uniform, adding them arguably
simplifies.)

I don't think anyone ever suggested:

    X := X + 1 when X < Integer'Last;

;-)

- Bob

Re: stopping a loop iteration without exiting it

[Mehdi Saada]

You're right, it can be done with if statements.
But when what about goto <loop_name> ?
It does simplify things, making loop_name and <label> more similar.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-04 20:46, Robert A Duff wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> P.P.S. When-for-everyone is long overdue:
>>
>>     goto <label> when <condition>;
>>     return [<result>] when <condition>;
>>     raise <exception> [with <message>] when <condition>;
> 
> Those were all proposed for Ada 9X.  They were rejected,
> IIRC, because they're mere "nice to haves", and the mood
> was generally "simplify by removing features".  (Since the
> above make the language more uniform, adding them arguably
> simplifies.)

Yes, if you cannot reject it for being too complex, then blame it too 
simple. (:-))

> I don't think anyone ever suggested:
> 
>      X := X + 1 when X < Integer'Last; 

I thought about really important cases, but could not invent syntax:

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

and

    if P /= null then
       declare
          X : P_Type renames P.all;
       begin
          ...
       end;
    end if;

and

    declare
       X : Access_To_Parent_Class := new Derived;
       Same_X : Derived renames Derived (X.all);
    begin
       ...
       return X; -- Parent's class result
    end;

a combination of a test and a renaming.

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

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-04 23:17 , Dmitry A. Kazakov wrote:

    [snip]

> I thought about really important cases, but could not invent syntax:
>
>    if X in T'Class then
>       declare
>          Same_X : T'Class renames T'Class (X);
>       begin
>          ...
>       end;
>    end if;

A syntax suggestion, drawing on analogy with exception handlers:

    case X is
    when Same_X : T'Class =>
       ...
    when Same_X : U'Class =>  -- other named classes
       ...
    when others =>  -- always required
       ...
    end case;

This would be legal only if no two classes in the "whens" are related 
with "in", so that at most one "when S'Class" matches X.

>    if P /= null then
>       declare
>          X : P_Type renames P.all;
>       begin
>          ...
>       end;
>    end if;

Similarly, applying an implicit dereference to the selecting expression 
when it has an access type:

    case P is
    when X : P_Type =>
       ...
    when null =>  -- or "when others =>"
       ...
    end case;

A combination might be possible when P is an access-to-classwide:

    case P is
    when X : P_Type'Class =>
       ...
    when X : Q_Type'Class =>   -- other named classes
       ...
    when null =>  -- optional, can be included in "others".
       ...
    when others =>  -- not null, but some other class
       ...
    end case;

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

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-05 00:08, Niklas Holsti wrote:
> On 18-01-04 23:17 , Dmitry A. Kazakov wrote:
> 
>     [snip]
> 
>> I thought about really important cases, but could not invent syntax:
>>
>>    if X in T'Class then
>>       declare
>>          Same_X : T'Class renames T'Class (X);
>>       begin
>>          ...
>>       end;
>>    end if;
> 
> A syntax suggestion, drawing on analogy with exception handlers:
> 
>     case X is
>     when Same_X : T'Class =>
>        ...
>     when Same_X : U'Class =>  -- other named classes
>        ...
>     when others =>  -- always required
>        ...
>     end case;
> 
> This would be legal only if no two classes in the "whens" are related 
> with "in", so that at most one "when S'Class" matches X.

It looks nice, but is inconsistent, at least logically. T'Class and 
U'Class always overlap. Differently to this case, which is logically OK:

    case X'Tag is  -- Tag to denote "type"?
       when Same_X : T =>
          ...
       when Same_X : U =>  -- other instances
          ...
       when others =>  -- always required
          ...
    end case;

>>    if P /= null then
>>       declare
>>          X : P_Type renames P.all;
>>       begin
>>          ...
>>       end;
>>    end if;
> 
> Similarly, applying an implicit dereference to the selecting expression 
> when it has an access type:
> 
>     case P is
>     when X : P_Type =>
>        ...
>     when null =>  -- or "when others =>"
>        ...
>     end case;

But as heavy weight as if-declare ...

However the idea of re-using exception handler style declarations could 
be very helpful in general cases. For example this is very frequent in 
parsers and protocol handlers:

    declare
       Symbol : constant Character := Get_Character;
    begin
       case Symbol is
          when '0'..'9' =>
             -- Process digit
          when 'A'..'Z' | 'a'..'z' =>
             -- Process letter

Much better this:

    case Get_Character is
       when Digit : '0'..'9' =>
          -- Process digit
       when Letter : 'A'..'Z' | 'a'..'z' =>
          -- Process letter

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

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-05 10:38 , Dmitry A. Kazakov wrote:
> On 2018-01-05 00:08, Niklas Holsti wrote:
>> On 18-01-04 23:17 , Dmitry A. Kazakov wrote:
>>
>>     [snip]
>>
>>> I thought about really important cases, but could not invent syntax:
>>>
>>>    if X in T'Class then
>>>       declare
>>>          Same_X : T'Class renames T'Class (X);
>>>       begin
>>>          ...
>>>       end;
>>>    end if;
>>
>> A syntax suggestion, drawing on analogy with exception handlers:
>>
>>     case X is
>>     when Same_X : T'Class =>
>>        ...
>>     when Same_X : U'Class =>  -- other named classes
>>        ...
>>     when others =>  -- always required
>>        ...
>>     end case;
>>
>> This would be legal only if no two classes in the "whens" are related
>> with "in", so that at most one "when S'Class" matches X.
>
> It looks nice, but is inconsistent, at least logically. T'Class and
> U'Class always overlap.

How so? Do the letters T and U have some special meaning to you?

If we have

    type Root is tagged ...

    type T is new Root ...

    type U is new Root ...

the T'Class and U'Class do not overlap. But if "U is new T ..." then 
they overlap.

> Differently to this case, which is logically OK:
>
>    case X'Tag is  -- Tag to denote "type"?
>       when Same_X : T =>
>          ...
>       when Same_X : U =>  -- other instances
>          ...
>       when others =>  -- always required
>          ...
>    end case;

That could be a different "case", which is not class-wide.

>>>    if P /= null then
>>>       declare
>>>          X : P_Type renames P.all;
>>>       begin
>>>          ...
>>>       end;
>>>    end if;
>>
>> Similarly, applying an implicit dereference to the selecting
>> expression when it has an access type:
>>
>>     case P is
>>     when X : P_Type =>
>>        ...
>>     when null =>  -- or "when others =>"
>>        ...
>>     end case;
>
> But as heavy weight as if-declare ...

Yes, not much of an improvement, but it could remove one level of 
indentation (depending on how one indents the "whens").

> However the idea of re-using exception handler style declarations could
> be very helpful in general cases. For example this is very frequent in
> parsers and protocol handlers:
>
>    declare
>       Symbol : constant Character := Get_Character;
>    begin
>       case Symbol is
>          when '0'..'9' =>
>             -- Process digit
>          when 'A'..'Z' | 'a'..'z' =>
>             -- Process letter
>
> Much better this:
>
>    case Get_Character is
>       when Digit : '0'..'9' =>
>          -- Process digit
>       when Letter : 'A'..'Z' | 'a'..'z' =>
>          -- Process letter

Yes, that would be nice in such cases, and would perhaps be easier to 
get approved by the ARG, because it should be completely compatible with 
current Ada.

The "case" forms with an (access to a) class-wide selector might 
introduce some incompatibility because they would enlarge the set of 
expected types of the selector expression.

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

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-06 17:50, Niklas Holsti wrote:
> On 18-01-05 10:38 , Dmitry A. Kazakov wrote:
>> On 2018-01-05 00:08, Niklas Holsti wrote:
>>> On 18-01-04 23:17 , Dmitry A. Kazakov wrote:
>>>
> If we have
> 
>     type Root is tagged ...
> 
>     type T is new Root ...
> 
>     type U is new Root ...
> 
> the T'Class and U'Class do not overlap. But if "U is new T ..." then 
> they overlap.

And what will be selected? The semantic of case is of mutually exclusive 
choices, so that the order of the choices were irrelevant. This is why 
if- or independent statements were preferable for type tests. However 
detection of overlapping alternatives would be nice for writing safe 
code. But that would require type ranges (see below) to resolve clashes 
and, that will not work in generics. (That mess taints everything) So, 
no chance.

>> Differently to this case, which is logically OK:
>>
>>    case X'Tag is  -- Tag to denote "type"?
>>       when Same_X : T =>
>>          ...
>>       when Same_X : U =>  -- other instances
>>          ...
>>       when others =>  -- always required
>>          ...
>>    end case;
> 
> That could be a different "case", which is not class-wide.

It is same to me. Compare it with this:

    case Int is
       when 1 =>
          -- Single value
       when 5..Integer'Last =>
          -- A range of values

T is a single type. T'Class is a range of types similar to 
5..Integer'Last. Certainly definite ranges of types must be supported as 
well:

    X in T..S

which same as

    X in T'Class and T in S'Class and (X in S or else X not in S'Class)

But the point is that it is the type of X not its value as it appears 
when reading "case X is".

>> However the idea of re-using exception handler style declarations could
>> be very helpful in general cases. For example this is very frequent in
>> parsers and protocol handlers:
>>
>>    declare
>>       Symbol : constant Character := Get_Character;
>>    begin
>>       case Symbol is
>>          when '0'..'9' =>
>>             -- Process digit
>>          when 'A'..'Z' | 'a'..'z' =>
>>             -- Process letter
>>
>> Much better this:
>>
>>    case Get_Character is
>>       when Digit : '0'..'9' =>
>>          -- Process digit
>>       when Letter : 'A'..'Z' | 'a'..'z' =>
>>          -- Process letter
> 
> Yes, that would be nice in such cases, and would perhaps be easier to 
> get approved by the ARG, because it should be completely compatible with 
> current Ada.

I am afraid that would fall under the category "too simple to be 
approved", together with "raise when", "return when", "goto when".

> The "case" forms with an (access to a) class-wide selector might 
> introduce some incompatibility because they would enlarge the set of 
> expected types of the selector expression.

I think it has the same problem as with type tests.

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

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-06 19:20 , Dmitry A. Kazakov wrote:
> On 2018-01-06 17:50, Niklas Holsti wrote:
>> On 18-01-05 10:38 , Dmitry A. Kazakov wrote:
>>> On 2018-01-05 00:08, Niklas Holsti wrote:
>>>> On 18-01-04 23:17 , Dmitry A. Kazakov wrote:
>>>>
>> If we have
>>
>>     type Root is tagged ...
>>
>>     type T is new Root ...
>>
>>     type U is new Root ...
>>
>> the T'Class and U'Class do not overlap. But if "U is new T ..." then
>> they overlap.
>
> And what will be selected? The semantic of case is of mutually exclusive
> choices, so that the order of the choices were irrelevant.

Well, that was what I suggested, that the "case" would require all 
choices to be non-overlapping, and therefore mutually exclusive.

Yes, in generics it would not always be possible to decide whether two 
formal types overlap, so either the "case" would be illegal there, or it 
could be defined as a non-deterministic choice.

> ... But that would require type ranges (see below) to resolve clashes

    [snip]

> T is a single type. T'Class is a range of types similar to
> 5..Integer'Last. Certainly definite ranges of types must be supported as
> well:
>
>    X in T..S
>
> which same as
>
>    X in T'Class and T in S'Class and (X in S or else X not in S'Class)

That is a bit hard to understand. Are you mixing into this condition 
both a definition of when T..S would be a legal "type range", and a 
definition of the membership test, X in T..S? Please clarify.

> But the point is that it is the type of X not its value as it appears
> when reading "case X is".

For class-wide types, the "type of X" (i.e. the tag of X) is part of the 
value of X, IMO. But I would not mind if the syntax would require "case 
X'Tag is".

However, I do think there is a clear (and perhaps valuable) difference 
between the forms

    when Same_X : T =>

where the object Same_X would not be class-wide, and

    when Same_X : U'Class =>

where the object Same_X would be class-wide. One could admit both kinds 
of "when" in the same "case", of course, as long and they are 
non-overlapping.

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

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-07 12:36, Niklas Holsti wrote:
> On 18-01-06 19:20 , Dmitry A. Kazakov wrote:

>> T is a single type. T'Class is a range of types similar to
>> 5..Integer'Last. Certainly definite ranges of types must be supported as
>> well:
>>
>>    X in T..S
>>
>> which same as
>>
>>    X in T'Class and T in S'Class and (X in S or else X not in S'Class)
> 
> That is a bit hard to understand.

If you want to have mutually exclusive alternatives you need type 
ranges. If S is a descendant of T then in order to build a case you have 
to spell choices like:

    when T..S'Parent =>
    when S'Class =>

X in T..S'Parent = X in T'Class and X not in S'Class and T in S'Class. 
The equivalent cannot be written as an alternative. And you cannot 
declare a corresponding set of types either, because there is no support 
for set-theoretic operations on types and classes: e.g.

    X'Class - S'Class = X..S'Parent

> However, I do think there is a clear (and perhaps valuable) difference 
> between the forms
> 
>     when Same_X : T =>
> 
> where the object Same_X would not be class-wide, and
> 
>     when Same_X : U'Class =>
> 
> where the object Same_X would be class-wide. One could admit both kinds 
> of "when" in the same "case", of course, as long and they are 
> non-overlapping.

It is the same form only the tests and resulting types are different.

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

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-07 14:05 , Dmitry A. Kazakov wrote:
> On 2018-01-07 12:36, Niklas Holsti wrote:
>> On 18-01-06 19:20 , Dmitry A. Kazakov wrote:
>
>>> T is a single type. T'Class is a range of types similar to
>>> 5..Integer'Last. Certainly definite ranges of types must be supported as
>>> well:
>>>
>>>    X in T..S
>>>
>>> which same as
>>>
>>>    X in T'Class and T in S'Class and (X in S or else X not in S'Class)
>>
>> That is a bit hard to understand.
>
> If you want to have mutually exclusive alternatives you need type
> ranges.

Ok, I understand you now, and yes, you are right, if you want to 
include, in the same (hypothetical) class-based "case" statement, 
related cases at different levels in the class hierarchy. But there is 
an alternative: use nested "case" statements, one per level.

> If S is a descendant of T then in order to build a case you have
> to spell choices like:
>
>    when T..S'Parent =>
>    when S'Class =>
>
> X in T..S'Parent = X in T'Class and X not in S'Class and T in S'Class.

Yes, but I think your formula has a mistake. You assume that S is a 
descendant of T, but the formula requires that T is in S'Class, which 
under your assumption happens only if S = T. Perhaps you meant "S in 
T'Class"?

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

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-07 22:22, Niklas Holsti wrote:
> On 18-01-07 14:05 , Dmitry A. Kazakov wrote:

>> If S is a descendant of T then in order to build a case you have
>> to spell choices like:
>>
>>    when T..S'Parent =>
>>    when S'Class =>
>>
>> X in T..S'Parent = X in T'Class and X not in S'Class and T in S'Class.
> 
> Yes, but I think your formula has a mistake. You assume that S is a 
> descendant of T, but the formula requires that T is in S'Class, which 
> under your assumption happens only if S = T. Perhaps you meant "S in 
> T'Class"?

Yes, S in T'Class.

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

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p2r0h8$9qr$1@gioia.aioe.org...
...
> I am afraid that would fall under the category "too simple to be 
> approved", together with "raise when", "return when", "goto when".

As usual in these cases, no one has asked. It's probably more of a case of 
"too simple to bother asking for".  And if you don't ask, there is 
absolutely no chance because it isn't on the ARG's radar.

Anyway, this is good a time as any to remind everyone that the deadline for 
public suggestions for Ada 2020 is next Monday (January 15th).

                     Randy Brukardt, ARG Editor.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-08 21:57, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p2r0h8$9qr$1@gioia.aioe.org...
> ...
>> I am afraid that would fall under the category "too simple to be
>> approved", together with "raise when", "return when", "goto when".
> 
> As usual in these cases, no one has asked.

It appears that raise|return|goto when was considered and rejected.

> It's probably more of a case of
> "too simple to bother asking for".  And if you don't ask, there is
> absolutely no chance because it isn't on the ARG's radar.

Making a formal request requires a language lawyer. Unfortunately there 
is no Ada public defender's office ... (:-))

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

Submitting requests to the ARG, was: Re: stopping a loop iteration without exiting it

[Simon Clubley]

On 2018-01-08, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2018-01-08 21:57, Randy Brukardt wrote:
>> And if you don't ask, there is
>> absolutely no chance because it isn't on the ARG's radar.
>
> Making a formal request requires a language lawyer. Unfortunately there 
> is no Ada public defender's office ... (:-))
>

I don't know if Dmitry is joking or not, but language lawyers most
certainly are _not_ required when submitting an issue to the ARG.

You just need to provide clear examples of your reasoning and maybe
some suggestions about what you would like the new syntax or
semantics to look like and why.

Most important however, is that you _MUST_ state at the beginning
of your submission what it is that you think Ada is missing and
what your proposal brings to Ada.

Everything else in your proposal should follow on from that; there's
no point in submitting unstructured paragraphs of text to the ARG
that don't state _what_ you are asking to be fixed in Ada and why.

Just make your submission readable, give _clear_ reasons for it,
and provide examples that clarify your reasoning or concerns.

That's all I had to do. (Oh, and make sure you register for the
ARG mailing list so that you can read the responses; the initial
period after you submit your proposal is a two-way process where
you can respond to questions and comments about your proposal.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Submitting requests to the ARG, was: Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 08/01/2018 22:48, Simon Clubley wrote:
> On 2018-01-08, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2018-01-08 21:57, Randy Brukardt wrote:
>>> And if you don't ask, there is
>>> absolutely no chance because it isn't on the ARG's radar.
>>
>> Making a formal request requires a language lawyer. Unfortunately there
>> is no Ada public defender's office ... (:-))
> 
> I don't know if Dmitry is joking or not, but language lawyers most
> certainly are _not_ required when submitting an issue to the ARG.
> 
> You just need to provide clear examples of your reasoning and maybe
> some suggestions about what you would like the new syntax or
> semantics to look like and why.
> 
> Most important however, is that you _MUST_ state at the beginning
> of your submission what it is that you think Ada is missing and
> what your proposal brings to Ada.
> 
> Everything else in your proposal should follow on from that; there's
> no point in submitting unstructured paragraphs of text to the ARG
> that don't state _what_ you are asking to be fixed in Ada and why.
> 
> Just make your submission readable, give _clear_ reasons for it,
> and provide examples that clarify your reasoning or concerns.
> 
> That's all I had to do. (Oh, and make sure you register for the
> ARG mailing list so that you can read the responses; the initial
> period after you submit your proposal is a two-way process where
> you can respond to questions and comments about your proposal.)

Sure. And representing the case in a favorable light is all what a 
lawyer does. He must push right buttons at right places, which not 
necessarily has anything to do with the merits of the proposal, 
especially of a trivial one like "raise when" or "goto <loop-label>".

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

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/08/2018 09:57 PM, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p2r0h8$9qr$1@gioia.aioe.org...
> ...
>> I am afraid that would fall under the category "too simple to be
>> approved", together with "raise when", "return when", "goto when".
> 
> As usual in these cases, no one has asked. It's probably more of a case of
> "too simple to bother asking for".  And if you don't ask, there is
> absolutely no chance because it isn't on the ARG's radar.

I asked for it once during a prior revision cycle. It was rejected. Doesn't seem 
to be any point in asking again.

-- 
Jeff Carter
"You can never forget too much about C++."
115

Re: stopping a loop iteration without exiting it

[Robert A Duff]

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

> I thought about really important cases, but could not invent syntax:
>
>    if X in T'Class then
>       declare
>          Same_X : T'Class renames T'Class (X);

That's something like pattern matching in languages
like OCaml.

- Bob

Re: stopping a loop iteration without exiting it

[G. B.]

Robert A Duff <bobduff@TheWorld.com> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> I thought about really important cases, but could not invent syntax:
>> 
>> if X in T'Class then
>> declare
>> Same_X : T'Class renames T'Class (X);
> 
> That's something like pattern matching in languages
> like OCaml.

Swift adds convenience:

   if let Same_X = X as? T {
      ...
   }

“=“ goes with “let”; if the downcast fails, the
result is nil, and the condition becomes false.

Re: stopping a loop iteration without exiting it

[Niklas Holsti]

On 18-01-04 23:17 , Dmitry A. Kazakov wrote:

> I thought about really important cases, but could not invent syntax:
>
>    if X in T'Class then
>       declare
>          Same_X : T'Class renames T'Class (X);
>       begin
>          ...
>       end;
>    end if;

I suggested and we discussed a form of "case" statement as new syntax 
for this. Here is another syntax suggestion using the keyword "is" to 
form a new kind of membership test, which also assigns a new name to the 
object when the test succeeds:

    if X is Same_X : T'Class then
       ...
    end if;

Another form, retaining the "in", could be

    if X is Same_X in T'Class then
       ...
    end if;

>    if P /= null then
>       declare
>          X : P_Type renames P.all;
>       begin
>          ...
>       end;
>    end if;

    if P.all is X : P_Type then
       ...
    end if;

where there would have to be a rule that the membership test is false if 
P is null, without raising Constraint_Error.

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

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-07 12:52, Niklas Holsti wrote:
> On 18-01-04 23:17 , Dmitry A. Kazakov wrote:
> 
>> I thought about really important cases, but could not invent syntax:
>>
>>    if X in T'Class then
>>       declare
>>          Same_X : T'Class renames T'Class (X);
>>       begin
>>          ...
>>       end;
>>    end if;
> 
> I suggested and we discussed a form of "case" statement as new syntax 
> for this. Here is another syntax suggestion using the keyword "is" to 
> form a new kind of membership test, which also assigns a new name to the 
> object when the test succeeds:
> 
>     if X is Same_X : T'Class then
>        ...
>     end if;
> 
> Another form, retaining the "in", could be
> 
>     if X is Same_X in T'Class then
>        ...
>     end if;

I think keeping colon in declarations is important.

>>    if P /= null then
>>       declare
>>          X : P_Type renames P.all;
>>       begin
>>          ...
>>       end;
>>    end if;
> 
>     if P.all is X : P_Type then
>        ...
>     end if;
> 
> where there would have to be a rule that the membership test is false if 
> P is null, without raising Constraint_Error.

Or ".all" just dropped as in the cases like array indexing.

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

Re: stopping a loop iteration without exiting it

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
[...]
> P.S. What I don't understand is why loop names cannot serve as labels. 
> Why this:
>
> loop
>     ...
>     goto Continue;
>     ...
>     <<Continue>>
> end loop;
>
> Instead of simple:
>
> Process : loop
>     ...
>     goto Process;
>     ...
> end loop Process;

So you want "goto Loop_Name" to branch to the *bottom* of the loop, not
the top?  I think that would confuse a lot of people.  If such a feature
were to be added, you might as well call it "continue".

> P.P.S. When-for-everyone is long overdue:
>
>     goto <label> when <condition>;
>     return [<result>] when <condition>;
>     raise <exception> [with <message>] when <condition>;

One data point: Perl has a postfix if.

    if ($condition) {
        do_something();
    }

    do_something() if $condition;

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-06 01:53, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [...]
>> P.S. What I don't understand is why loop names cannot serve as labels.
>> Why this:
>>
>> loop
>>      ...
>>      goto Continue;
>>      ...
>>      <<Continue>>
>> end loop;
>>
>> Instead of simple:
>>
>> Process : loop
>>      ...
>>      goto Process;
>>      ...
>> end loop Process;
> 
> So you want "goto Loop_Name" to branch to the *bottom* of the loop, not
> the top?

The loop top and bottom are logically the same place. That is what loop 
actually means.

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

Re: stopping a loop iteration without exiting it

[gautier_niouzes]

> The loop top and bottom are logically the same place. That is what loop 
> actually means.

Not so simple! With a for loop (say for i in 1..10 loop), a "goto top of loop" would mean redo the same iteration i, a "goto bottom of loop" would mean increment i or exit if i=10.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-06 09:49, gautier_niouzes@hotmail.com wrote:
>> The loop top and bottom are logically the same place. That is what loop
>> actually means.
> 
> Not so simple! With a for loop (say for i in 1..10 loop), a "goto
> top  of loop" would mean redo the same iteration i, a "goto bottom of loop"
> would mean increment i or exit if i=10.

The top of the loop /= the top of the loop body. Note the loop label 
location. It is at the loop top=bottom:

    Repeat : for I in 1..10 loop

not at the beginning of the loop body:

    for I in 1..10 Repeat : loop

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

Re: stopping a loop iteration without exiting it

[mockturtle]

On Saturday, January 6, 2018 at 9:49:48 AM UTC+1, gautier...@hotmail.com wrote:
> > The loop top and bottom are logically the same place. That is what loop 
> > actually means.
> 
> Not so simple! With a for loop (say for i in 1..10 loop), a "goto top of loop" would mean redo the same iteration i, a "goto bottom of loop" would mean increment i or exit if i=10.

Well, remaining in this hypothetical syntax, I could suggest

   goto end Loop_Name

or even

    goto end of Loop_Name

since "end" and "of" are already keywords.  Maybe at first sight one could mistake as a request to exit the loop, but I guess that you'll learn fast the real meaning

Re: stopping a loop iteration without exiting it

[AdaMagica]

Process : loop
     ...
     goto Process;
     ...
end loop Process;

For me, this looks like the loop is restarted from the beginning, as is the case here:

<<Process>> : loop
     ...
     goto Process;
     ...
end loop;

So, no, goto to the loop name is a very bad idea.

We have a simple solution with goto that is unambiguous

loop
     ...
     goto Continue;
     ...
<<Continue>> end loop;

so why on earth can't we save our time and go on to discussing more important problems with Ada? In the Ada Issues, you can find a lot of unsolved problems. Put your gray cells there!

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 09/01/2018 12:05, AdaMagica wrote:
> Process : loop
>       ...
>       goto Process;
>       ...
> end loop Process;
> 
> For me, this looks like the loop is restarted from the beginning

Which is exactly what loop continuation/next iteration is.

> so why on earth can't we save our time and go on to discussing more
> important problems with Ada?

Important problems have solutions "too complex" to be adopted.

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

Re: stopping a loop iteration without exiting it

[Simon Wright]

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

> On 09/01/2018 12:05, AdaMagica wrote:
>> Process : loop
>>       ...
>>       goto Process;
>>       ...
>> end loop Process;
>>
>> For me, this looks like the loop is restarted from the beginning
>
> Which is exactly what loop continuation/next iteration is.

Loop continuation/next iteration is exactly *not* restarting from the
beginning.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 09/01/2018 13:50, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 09/01/2018 12:05, AdaMagica wrote:
>>> Process : loop
>>>        ...
>>>        goto Process;
>>>        ...
>>> end loop Process;
>>>
>>> For me, this looks like the loop is restarted from the beginning
>>
>> Which is exactly what loop continuation/next iteration is.
> 
> Loop continuation/next iteration is exactly *not* restarting from the
> beginning.

Of course it is. Unless under "restarting" you mean not repeating the 
loop's top and body, but repeating the loop statement as a whole, which 
would be silly to do.

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

Re: stopping a loop iteration without exiting it

[Dennis Lee Bieber]

On Tue, 9 Jan 2018 14:07:41 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> declaimed the following:

>On 09/01/2018 13:50, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On 09/01/2018 12:05, AdaMagica wrote:
>>>> Process : loop
>>>>        ...
>>>>        goto Process;
>>>>        ...
>>>> end loop Process;
>>>>
>>>> For me, this looks like the loop is restarted from the beginning
>>>
>>> Which is exactly what loop continuation/next iteration is.
>> 
>> Loop continuation/next iteration is exactly *not* restarting from the
>> beginning.
>
>Of course it is. Unless under "restarting" you mean not repeating the 
>loop's top and body, but repeating the loop statement as a whole, which 
>would be silly to do.

	But the label IS before the loop statement, so going to the label does
give the visual impression that one is restarting the entire loop...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 09/01/2018 14:47, Dennis Lee Bieber wrote:
> On Tue, 9 Jan 2018 14:07:41 +0100, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> declaimed the following:
> 
>> On 09/01/2018 13:50, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> On 09/01/2018 12:05, AdaMagica wrote:
>>>>> Process : loop
>>>>>         ...
>>>>>         goto Process;
>>>>>         ...
>>>>> end loop Process;
>>>>>
>>>>> For me, this looks like the loop is restarted from the beginning
>>>>
>>>> Which is exactly what loop continuation/next iteration is.
>>>
>>> Loop continuation/next iteration is exactly *not* restarting from the
>>> beginning.
>>
>> Of course it is. Unless under "restarting" you mean not repeating the
>> loop's top and body, but repeating the loop statement as a whole, which
>> would be silly to do.
> 
> 	But the label IS before the loop statement, so going to the label does
> give the visual impression that one is restarting the entire loop...

No, because the same label is also *after* the loop statement:

       ...
    end loop Process;
             ^^^^^^^

And the label is used in the exit statement too. Shouldn't

    exit Process;

repeat all loop again?

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

Re: stopping a loop iteration without exiting it

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
.
> 
> No, because the same label is also *after* the loop statement:

which shows that having *goto* jump to indicators
of another control structure destroys it as a building block.
Rubble is what you get.

No need.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 09/01/2018 21:07, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> .
>> No, because the same label is also *after* the loop statement:
> 
> which shows that having *goto* jump to indicators
> of another control structure destroys it as a building block.

I have no idea what this is supposed to mean.

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

Re: stopping a loop iteration without exiting it

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 09/01/2018 21:07, G. B. wrote:
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> .
>>> No, because the same label is also *after* the loop statement:
>> 
>> which shows that having *goto* jump to indicators
>> of another control structure destroys it as a building block.
> 
> I have no idea what this is supposed to mean.


L:
[for|while...] loop
   ...
   goto L;
   ...
end loop L;

Both outer Ls are part of what indicates the beginning
and end of the loop, resp. So, as others said in this thread,
there is syntactical ambiguity when using L with goto. 
The meaning of the goto L is not clear or agreed upon
either, as readers here have said. 

A loop statement is a means of controlling flow. So is goto.
A loop controls iteration. Suppose that an additional
goto is needed to express that. Then this thread will
have discovered that Ada loops are deficient as building
blocks of iteration.

Re: stopping a loop iteration without exiting it

[AdaMagica]

Am Mittwoch, 10. Januar 2018 22:15:00 UTC+1 schrieb G. B.:
> A loop statement is a means of controlling flow. So is goto.
> A loop controls iteration. Suppose that an additional
> goto is needed to express that. Then this thread will
> have discovered that Ada loops are deficient as building
> blocks of iteration.

???????

Re: stopping a loop iteration without exiting it

[G. B.]

AdaMagica <christ-usch.grein@t-online.de> wrote:
> Am Mittwoch, 10. Januar 2018 22:15:00 UTC+1 schrieb G. B.:
>> A loop statement is a means of controlling flow. So is goto.
>> A loop controls iteration. Suppose that an additional
>> goto is needed to express that. Then this thread will
>> have discovered that Ada loops are deficient as building
>> blocks of iteration.
> 
> ???????
> 

If a loop needs “goto”, then “loop” is broken.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-10 22:14, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 09/01/2018 21:07, G. B. wrote:
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> .
>>>> No, because the same label is also *after* the loop statement:
>>>
>>> which shows that having *goto* jump to indicators
>>> of another control structure destroys it as a building block.
>>
>> I have no idea what this is supposed to mean.
> 
> 
> L:
> [for|while...] loop
>     ...
>     goto L;
>     ...
> end loop L;
> 
> Both outer Ls are part of what indicates the beginning
> and end of the loop, resp. So, as others said in this thread,
> there is syntactical ambiguity when using L with goto.
> The meaning of the goto L is not clear or agreed upon
> either, as readers here have said.

Substitute "exit" for "goto" and reread your text.

> A loop statement is a means of controlling flow. So is goto.
> A loop controls iteration. Suppose that an additional
> goto is needed to express that. Then this thread will
> have discovered that Ada loops are deficient as building
> blocks of iteration.

Substitute "if" for "goto".

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

Re: stopping a loop iteration without exiting it

[Simon Wright]

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

>> L:
>> [for|while...] loop
>>     ...
>>     goto L;
>>     ...
>> end loop L;
>>
>> Both outer Ls are part of what indicates the beginning
>> and end of the loop, resp. So, as others said in this thread,
>> there is syntactical ambiguity when using L with goto.
>> The meaning of the goto L is not clear or agreed upon
>> either, as readers here have said.
>
> Substitute "exit" for "goto" and reread your text.

Sorry, but those are not the same. "exit" clearly means to leave the
loop; there's no way it could be interpreted as restarting the loop
completely. "goto" on the other hand, now I see it laid out like that,
certainly has the possibility of confusion.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 2018-01-11 18:11, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> L:
>>> [for|while...] loop
>>>      ...
>>>      goto L;
>>>      ...
>>> end loop L;
>>>
>>> Both outer Ls are part of what indicates the beginning
>>> and end of the loop, resp. So, as others said in this thread,
>>> there is syntactical ambiguity when using L with goto.
>>> The meaning of the goto L is not clear or agreed upon
>>> either, as readers here have said.
>>
>> Substitute "exit" for "goto" and reread your text.
> 
> Sorry, but those are not the same. "exit" clearly means to leave the
> loop; there's no way it could be interpreted as restarting the loop
> completely. "goto" on the other hand, now I see it laid out like that,
> certainly has the possibility of confusion.

If there is no way to interpret exit as exit before the loop, then there 
is none for goto and conversely.

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

Re: stopping a loop iteration without exiting it

[Simon Wright]

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

> On 2018-01-11 18:11, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>>> L:
>>>> [for|while...] loop
>>>>      ...
>>>>      goto L;
>>>>      ...
>>>> end loop L;
>>>>
>>>> Both outer Ls are part of what indicates the beginning
>>>> and end of the loop, resp. So, as others said in this thread,
>>>> there is syntactical ambiguity when using L with goto.
>>>> The meaning of the goto L is not clear or agreed upon
>>>> either, as readers here have said.
>>>
>>> Substitute "exit" for "goto" and reread your text.
>>
>> Sorry, but those are not the same. "exit" clearly means to leave the
>> loop; there's no way it could be interpreted as restarting the loop
>> completely. "goto" on the other hand, now I see it laid out like that,
>> certainly has the possibility of confusion.
>
> If there is no way to interpret exit as exit before the loop, then
> there is none for goto and conversely.

I lost track of the point you're trying to make, so I'll leave it there.
 

Re: stopping a loop iteration without exiting it

[G. B.]

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

>>> I have no idea what this is supposed to mean.
>> 
>> 
>> L:
>> [for|while...] loop
>> ...
>> goto L;
>> ...
>> end loop L;
>> 
>> Both outer Ls are part of what indicates the beginning
>> and end of the loop, resp. So, as others said in this thread,
>> there is syntactical ambiguity when using L with goto.
>> The meaning of the goto L is not clear or agreed upon
>> either, as readers here have said.
> 
> Substitute "exit" for "goto" and reread your text.

When writing, I also thought about “return” and about 
exceptions, not just about “exit”. But none of them has
the potential of driving the iterative process, they just
leave it, the building block. It will be over. 

loop is intended for the opposite, for when it’s not over yet.
For when it’s done again. “exit” cannot mean that, but the
hypothesized goto can.



>> A loop statement is a means of controlling flow. So is goto.
>> A loop controls iteration. Suppose that an additional
>> goto is needed to express that. Then this thread will
>> have discovered that Ada loops are deficient as building
>> blocks of iteration.
> 
> Substitute "if" for "goto".

Actually, “if” itself cannot directly make the program
iterate, unlike “goto”.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 11/01/2018 21:54, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>>>> I have no idea what this is supposed to mean.
>>>
>>>
>>> L:
>>> [for|while...] loop
>>> ...
>>> goto L;
>>> ...
>>> end loop L;
>>>
>>> Both outer Ls are part of what indicates the beginning
>>> and end of the loop, resp. So, as others said in this thread,
>>> there is syntactical ambiguity when using L with goto.
>>> The meaning of the goto L is not clear or agreed upon
>>> either, as readers here have said.
>>
>> Substitute "exit" for "goto" and reread your text.
> 
> When writing, I also thought about “return” and about
> exceptions, not just about “exit”. But none of them has
> the potential of driving the iterative process, they just
> leave it, the building block. It will be over.

So what? In either case actions are non-trivial because they potentially 
involve finalization of objects and types.

> loop is intended for the opposite, for when it’s not over yet.
> For when it’s done again. “exit” cannot mean that, but the
> hypothesized goto can.

1. "exit" can:

    exit when <condition>;

When condition evaluates false the loop continues.

2. "goto" cannot in any deeper sense than "exit" does because it is not 
"goto" which would drive the loop in this case.

>>> A loop statement is a means of controlling flow. So is goto.
>>> A loop controls iteration. Suppose that an additional
>>> goto is needed to express that. Then this thread will
>>> have discovered that Ada loops are deficient as building
>>> blocks of iteration.
>>
>> Substitute "if" for "goto".
> 
> Actually, “if” itself cannot directly make the program
> iterate, unlike “goto”.

Not in the case at hand.

P.S. Take if + a subroutine call. That gives recursion. Then following 
your flawed logic either if or loop is bad.

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

Re: stopping a loop iteration without exiting it

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 11/01/2018 21:54, G. B. wrote:
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> 
>>>>> I have no idea what this is supposed to mean.
>>>> 
>>>> 
>>>> L:
>>>> [for|while...] loop
>>>> ...
>>>> goto L;
>>>> ...
>>>> end loop L;

>> loop is intended for the opposite, for when it’s not over yet.
>> For when it’s done again. “exit” cannot mean that, but the
>> hypothesized goto can.
> 
> 1. "exit" can:
> 
>    exit when <condition>;
> 
> When condition evaluates false the loop continues.
 
Well, no, the loop’s body continues. Doing so, it doesn’t
trigger another iteration, unlike “goto Continue”, or “goto L”.
It doesn’t drive.

Hence the following doesn’t apply to the case in point:
> 2. "goto" cannot in any deeper sense than "exit" does because it is not 
> "goto" which would drive the loop in this case.

>> Actually, “if” itself cannot directly make the program
>> iterate, unlike “goto”.
> 
> Not in the case at hand.

I’ll let your new case rest in your hands.


> P.S. Take if + a subroutine call. That gives recursion. Then following 
> your flawed logic either if or loop is bad.

Indeed this is a functionist’s main tenet. 
But then, if CALL and COND do not suffice, i.e., if they need 
an additional goto-like evaluation driver, then the functional
language is broken.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 12/01/2018 10:22, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 11/01/2018 21:54, G. B. wrote:
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>
>>>>>> I have no idea what this is supposed to mean.
>>>>>
>>>>>
>>>>> L:
>>>>> [for|while...] loop
>>>>> ...
>>>>> goto L;
>>>>> ...
>>>>> end loop L;
> 
>>> loop is intended for the opposite, for when it’s not over yet.
>>> For when it’s done again. “exit” cannot mean that, but the
>>> hypothesized goto can.
>>
>> 1. "exit" can:
>>
>>     exit when <condition>;
>>
>> When condition evaluates false the loop continues.
>   
> Well, no, the loop’s body continues. Doing so, it doesn’t
> trigger another iteration, unlike “goto Continue”, or “goto L”.
> It doesn’t drive.

goto Continue triggers nothing, no more than exit when False at the loop 
end or any last loop statement.

loop
    ...
    exit when False;
end loop;

>> P.S. Take if + a subroutine call. That gives recursion. Then following
>> your flawed logic either if or loop is bad.
> 
> Indeed this is a functionist’s main tenet.
> But then, if CALL and COND do not suffice, i.e., if they need
> an additional goto-like evaluation driver, then the functional
> language is broken.

Whatever, any non-minimal language is broken, who cares?

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

Re: stopping a loop iteration without exiting it

[AdaMagica]

Am Dienstag, 9. Januar 2018 14:07:43 UTC+1 schrieb Dmitry A. Kazakov:
> On 09/01/2018 13:50, Simon Wright wrote:
> > "Dmitry A. Kazakov" writes:
> > 
> >> On 09/01/2018 12:05, AdaMagica wrote:
> >>> Process : loop
> >>>        ...
> >>>        goto Process;
> >>>        ...
> >>> end loop Process;
> >>>
> >>> For me, this looks like the loop is restarted from the beginning
> >>
> >> Which is exactly what loop continuation/next iteration is.
> > 
> > Loop continuation/next iteration is exactly *not* restarting from the
> > beginning.
> 
> Of course it is. Unless under "restarting" you mean not repeating the 
> loop's top and body, but repeating the loop statement as a whole, which 
> would be silly to do.

This is sophistry. Fact is that any syntax that might lead to ambiguities is not going to fly because it's incompatible with the basics of Ada.

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 10/01/2018 11:52, AdaMagica wrote:
> Am Dienstag, 9. Januar 2018 14:07:43 UTC+1 schrieb Dmitry A. Kazakov:
>> On 09/01/2018 13:50, Simon Wright wrote:
>>> "Dmitry A. Kazakov" writes:
>>>
>>>> On 09/01/2018 12:05, AdaMagica wrote:
>>>>> Process : loop
>>>>>         ...
>>>>>         goto Process;
>>>>>         ...
>>>>> end loop Process;
>>>>>
>>>>> For me, this looks like the loop is restarted from the beginning
>>>>
>>>> Which is exactly what loop continuation/next iteration is.
>>>
>>> Loop continuation/next iteration is exactly *not* restarting from the
>>> beginning.
>>
>> Of course it is. Unless under "restarting" you mean not repeating the
>> loop's top and body, but repeating the loop statement as a whole, which
>> would be silly to do.
> 
> This is sophistry.

Yes.

> Fact is that any syntax that might lead to
> ambiguities is not going to fly because it's incompatible with the
> basics of Ada.

I don't see any ambiguity as there is none in

    exit Process;

It exits the loop at its end, it does not jump to the point before the 
loop. So could do

    goto Process;

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

Re: stopping a loop iteration without exiting it

[AdaMagica]

Am Mittwoch, 10. Januar 2018 12:14:41 UTC+1 schrieb Dmitry A. Kazakov:
> On 10/01/2018 11:52, AdaMagica wrote:
> > Fact is that any syntax that might lead to
> > ambiguities is not going to fly because it's incompatible with the
> > basics of Ada.
> 
> I don't see any ambiguity as there is none in
> 
>     exit Process;
> 
> It exits the loop at its end, it does not jump to the point before the 
> loop. So could do
> 
>     goto Process;

This is sophistry again in pure form. Have you ever read Shakespear? "Exit Duncan" means, he leaves the stage and does not immediately enter again ;-)

Re: stopping a loop iteration without exiting it

[Dmitry A. Kazakov]

On 10/01/2018 12:21, AdaMagica wrote:
> Am Mittwoch, 10. Januar 2018 12:14:41 UTC+1 schrieb Dmitry A. Kazakov:
>> On 10/01/2018 11:52, AdaMagica wrote:
>>> Fact is that any syntax that might lead to
>>> ambiguities is not going to fly because it's incompatible with the
>>> basics of Ada.
>>
>> I don't see any ambiguity as there is none in
>>
>>      exit Process;
>>
>> It exits the loop at its end, it does not jump to the point before the
>> loop. So could do
>>
>>      goto Process;
> 
> This is sophistry again in pure form.

Right. That word is an abbreviation for "logical inference with an 
undesired outcome". (:-))

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

Re: stopping a loop iteration without exiting it

[Mart van de Wege]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 01/04/2018 12:17 AM, Robert A Duff wrote:
>>
>> Jeff's suggestion (nested 'if' in the loop) is a good one when it works,
>> but it doesn't work when the "continue" is nested within further control
>> constructs.
>
> I have never seen a real-world situation in which a "continue" was
> needed.

It's a common idiom in Perl when looping over a stream of discrete items
(like lines in a file). A test at the top of the loop for cases where
processing is not necessary in the form of

  next if <condition>

(a popular one is in file processing, to skip comment lines:

  next if /^#/;

aka, skip this line if it starts with a # character indicating a
comment)

Since these are basically guard clauses, the idiom is clear to anyone
with more than a cursory knowledge of the language (and anyone
pretending to be a programmer, let alone a software engineer, should be
smart enough to recognise this as the loop equivalent of a guard clause
on a second look).

The resistance against adding a similar construct to Ada is puzzling to
me. It is clear, and more elegant than the more general 'goto' that is
the only way to do this in Ada. Adding a goto with a label at the top of
the loop is not clear until you seek out the label near the 'end loop'
statement; if that is out of sight it may well appear as an attempt to
break out of the loop.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/04/2018 10:52 PM, Mart van de Wege wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>>
>> I have never seen a real-world situation in which a "continue" was
>> needed.
> 
> It's a common idiom in Perl when looping over a stream of discrete items
> (like lines in a file). A test at the top of the loop for cases where
> processing is not necessary in the form of
> 
>    next if <condition>

I hardly think Perl is a good example for Ada language design decisions. This 
appears to be exactly an example that can be replaced  by an if statement, anyway.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: stopping a loop iteration without exiting it

[Mart van de Wege]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 01/04/2018 10:52 PM, Mart van de Wege wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>>>
>>> I have never seen a real-world situation in which a "continue" was
>>> needed.
>>
>> It's a common idiom in Perl when looping over a stream of discrete items
>> (like lines in a file). A test at the top of the loop for cases where
>> processing is not necessary in the form of
>>
>>    next if <condition>
>
> I hardly think Perl is a good example for Ada language design
> decisions.

That answer is a bit parochial.

And you're moving the goalposts. No matter how messy Perl is as a
language, it is being used in the real world, and the use case of
processing a stream of discrete elements is not particularly rare.

The idiom is in common use, even if it is not in a language to your
liking, so your 'never seen a real-world situation' remark is simply not
true.

> This appears to be exactly an example that can be replaced
> by an if statement, anyway.

Creating an unnecessary extra block, making code less readable. And what
of the situation where you want to test for more than one exceptional
situation before handing over your input to the main body of the loop?
You want nested ifs?

In my opinion a 'continue' construct is a useful bit of syntactic sugar
that makes adding guard clauses to a loop easy and obvious to the reader
of the code.

It is by no means *necessary*. A goto statement works just the same.

(As an aside, could it not be implemented using Pre- and
Post-Conditions, just as in subprograms?)

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/05/2018 03:35 PM, Mart van de Wege wrote:
> 
> The idiom is in common use, even if it is not in a language to your
> liking, so your 'never seen a real-world situation' remark is simply not
> true.

I never said I've never seen a real-world situation in which such a construct is 
used. I said I've never seen one where it was needed.  That is still true.

> Creating an unnecessary extra block, making code less readable. And what
> of the situation where you want to test for more than one exceptional
> situation before handing over your input to the main body of the loop?
> You want nested ifs?

Code such that a single "if" will significantly impact the readability needs to 
be rethought anyway. If there are multiple tests, I am familiar with the "and" 
operator. If they need to be executed in a specific order, I am familiar with 
"and then". Nested ifs are unnecessary; I have no idea why you would think they 
would be.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: stopping a loop iteration without exiting it

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> I never said I've never seen a real-world situation in which such a
> construct is used. I said I've never seen one where it was needed.
> That is still true.

If a construct is useful, then the existence of an ugly workaround for
its absence doesn't make it non-useful.  Of course it's not "needed"; as
Mart van de Wege says, you could use GOTO for everything so none of it
is needed.  The question is whether it improves code readability,
reliability, developer productivity, etc.

Heck, there's an argument that in real-world projects, it *is* needed:
developers choose languages like C++ or even Perl because Ada is such a
pain in the neck by comparison.  So if you insist on using Ada for your
project, it simply doesn't get done.  I didn't get interested in Ada
myself until Ada 2012, which makes many things a lot easier.

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87shbki0et.fsf@nightsong.com...
...
> If a construct is useful, then the existence of an ugly workaround for
> its absence doesn't make it non-useful.

But "usefulness" by itself is not the question. Almost every special syntax 
proposed is useful for something. The question is more whether it is useful 
AND commonly used enough to be part of the language. Because every special 
language gadget has a cost in learning, readability, and the like. The 
larger a language is, the harder it is to learn and read, regardless of the 
merits of the individual features.

Also, in this case, making "continue" a reserved word would break a lot of 
existing code that uses gotos for this feature -- as "continue" is commonly 
used as the name of the label, and that would no longer be legal. So 
programmers who do this a lot would have a significant portability problem. 
Balancing that against the rarity of use for most programmers, and it didn't 
seem worth adding to Ada. (This was for Ada 2005, I believe.)

We (the ARG) have rules against asking precisely the same question that was 
previously answered, lest the same questions be considered over and over. So 
we wouldn't reconsider the decision on "continue" unless something 
significant has changed, and I don't think anything has.

                            Randy.

Re: stopping a loop iteration without exiting it

[G. B.]

Paul Rubin <no.email@nospam.invalid> wrote:
> "; as
> Mart van de Wege says, you could use GOTO for everything so none of it
> is needed.  The question is whether it improves code readability,
> reliability, developer productivity, etc.

Another question is what the alternative really is.
Having both read and written Perl text, I still find it 
more promising to start a filter written like this:

   loop
      Process (Line, Result => Classification);
      case Classification is
         when Throwaway =>
            null;
         when Hit =>
            Handle (Factory.Make (Input => Line));
         when Unclear =>
            Report (Line);
      end case;
      Get_Line (Line);
   end loop;

Subprogram Process then looks at a single line
of input, in a way that is similar to the pattern parts
of AWK programs. Actions are triggered by Handle
only.

Perl’s continue block has one noteworthy piece 
of design, I think. It allows expressing something 
that is going to happen each time around the loop
irrespective of the loop’s other control structure.
There doesn’t seem to be a way to express this
fact clearly in most languages, including Ada.
Conventions and idioms aren’t the same thing
as a special structure provided by the language.

 while (Conditions) {
   ...
 } continue {
   ...
 }

I am not convinced, though, that an uncontrollable 
iteration is a Good Thing.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/05/2018 08:13 PM, Paul Rubin wrote:
> 
> If a construct is useful, then the existence of an ugly workaround for
> its absence doesn't make it non-useful.  Of course it's not "needed"; as
> Mart van de Wege says, you could use GOTO for everything so none of it
> is needed.  The question is whether it improves code readability,
> reliability, developer productivity, etc.

When I say "needed", I of course mean needed to make the code significantly 
simpler or clearer than code without the "continue". In fact, my experience has 
been the opposite: excluding the majority of uses, which are equivalent to an 
"if" and are equivalent in simplicity and clearness, the real-world examples 
I've seen where people wanted or used a "continue" were simpler and clearer when 
reworked to avoid the "continue".

I'm willing to accept that there are cases where the construct would result in 
simpler or clearer code. People have claimed to have such cases, but I have not 
seen them. But based on my experience, there is no need for such a feature.

-- 
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:p2kufi$f1l$1@dont-email.me...
> On 01/04/2018 12:17 AM, Robert A Duff wrote:
>>
>> Jeff's suggestion (nested 'if' in the loop) is a good one when it works,
>> but it doesn't work when the "continue" is nested within further control
>> constructs.
>
> I have never seen a real-world situation in which a "continue" was needed. 
> The vast majority of times that I've seen where people have claimed they 
> needed it, it could be replaced by an "if". The few remaining cases 
> involved very convoluted and unreadable code. When it was rethought and 
> simplified, it no longer needed a "continue". I would be interested in 
> seeing real-world examples where it was needed.

Evey case where it is needed by its nature involves "convuluted code". To 
claim that such code can be simplified, however, defies my experience.

There are a number of instances of it in the spam filter. When it is 
determined that a particular pattern cannot possibly match, one does a 
"continue" to move on to the next pattern. This is usually in an inner loop 
(so this is acting as a combination exit and continue). The rules for the 
spam filter turn out to be very complex, so the code implementing them also 
end up complex; simplifying the rules leads to allowing spam through or 
blocking "ham" (good mail).

                               Randy.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/05/2018 02:17 AM, Randy Brukardt wrote:
> 
> There are a number of instances of it in the spam filter. When it is
> determined that a particular pattern cannot possibly match, one does a
> "continue" to move on to the next pattern. This is usually in an inner loop
> (so this is acting as a combination exit and continue). The rules for the
> spam filter turn out to be very complex, so the code implementing them also
> end up complex; simplifying the rules leads to allowing spam through or
> blocking "ham" (good mail).

and also (in another post):

> It's not a frequent need, it's just a non-zero need. I find I end up up 
> writing such a goto (very roughly) once a year. But a good number of them 
> aren't strict continues; there's often something at the bottom of the loop 
> after the label.

I don't know of any language that has a "continue" that will apply to any but 
the innermost containing loop, so such languages would not seem to have any 
advantage in this case anyway. I suppose Ada could be the 1st with such a feature.

I don't know of any language with a "continue-like" feature that includes 
executing some code at the end of the continued loop. I can't imagine what such 
a feature might even look like.

But it appears that even if Ada had a "continue" feature, it might not replace 
the goto of many of your real-world examples.

I've never written a spam filter, but I'd imagine that one would be structured 
something like

All_Msgs : loop
    exit All_Msgs when Msg_Source.Is_Empty;

    Msg := Msg_Source.Get;
    Is_Spam := False;

    All_Patterns : for Pattern of Patterns loop
       Is_Spam := Pattern.Check (Msg);

       if Is_Spam then
          Reject (Message => Msg);

          exit All_Patterns;
       end if;
    end loop All_Patterns;

    if not Is_Spam then
       Allow (Message => Msg);
    end if;
end loop All_Msgs;

and moving on to the next pattern would be "return False;" in Check. Reality is 
probably more complex than this.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:p2o0mp$brp$1@dont-email.me...
...
> I've never written a spam filter, but I'd imagine that one would be 
> structured something like
>
> All_Msgs : loop
>    exit All_Msgs when Msg_Source.Is_Empty;
>
>    Msg := Msg_Source.Get;
>    Is_Spam := False;
>
>    All_Patterns : for Pattern of Patterns loop
>       Is_Spam := Pattern.Check (Msg);
>
>       if Is_Spam then
>          Reject (Message => Msg);
>
>          exit All_Patterns;
>       end if;
>    end loop All_Patterns;
>
>    if not Is_Spam then
>       Allow (Message => Msg);
>    end if;
> end loop All_Msgs;
>
> and moving on to the next pattern would be "return False;" in Check. 
> Reality is probably more complex than this.

Definitely. There are a number of different dispositions (Block [don't 
accept the message in the first place, not possible in this part of  the 
algorithm], Delete, Quarantine [for human inspection], or Allow). One also 
has to deal with white lists, and the possibility that a pattern might cause 
a white list trigger. I also have two levels of white list (allow 
unconditionally, or allow but quarantine questionable mail). And there are 
patterns specifically for different parts of the message (the text, the HTML 
markup, links, headers, etc.) Plus there are actions associated with the 
success or failure of certain patterns (such as checking linked websites for 
known spam sites). I've probably missed some cases, too.

                              Randy. 

Re: stopping a loop iteration without exiting it

[gautier_niouzes]

>     loop
>       ...
>              goto Continue;
>       ...
>     <<Continue>>
>     end loop;
> 
>                                   Randy.

I was about to suggest for Ada 2020 a "goto loop end", but the "goto Continue" has the advantage of showing that the goto jumps *before* the loop's end, reminding that further iterations may occur.

Re: stopping a loop iteration without exiting it

[Jeffrey R. Carter]

On 01/03/2018 05:54 PM, Mehdi Saada wrote:
> Is there a way to tell to ignore the remaining of a loop ? Like an exit statement, but instead of quiting the loop, it would go to the next iteration.
> Can we do this except with a recursive structure ?

Yes. It's called an if statement.

loop
    Do_Something;

    if not Condition then
       Do_Something_More;
    end if;
end loop;

Condition is your condition for going to the next iteration.

-- 
Jeff Carter
"Violence is the last refuge of the incompetent."
Foundation
151

Re: stopping a loop iteration without exiting it

[Mehdi Saada]

I have no knowledge of C, "continue" seems nice a priori, but I trust you it's a bad design choice. Ok !

Re: stopping a loop iteration without exiting it

[Matt Borchers]

I would like to also put my voice in for a 'next [when condition]' statement.  It is also my opinion that in some cases it is more readable.  I would avoid 'continue' only because it is a C term.  The use of 'goto' in a loop to act like a next by jumping to the END of the loop seems more like a hack and I agree with the sentiment that it adds more confusion for the reader.

Regarding performing a sequence of statements conditionally after a loop comes up quite a bit in my experience.  In our proprietary language we have a loop...then...end loop construct.  The 'then' block executes when the loop terminates normally (not terminated by an 'exit').  This can be useful when you want to do some action following the loop only when the loop runs 'cleanly' and it avoids having to create a Boolean flag variable to set in the loop with the addition of an 'if' statement and then have to test the flag following the loop with another 'if' block.

A similar situation occurs frequently with exceptions.  I would like to see a 'finally' block added after the 'when' conditions that runs after any handler is run.

begin
...
exception
  when EX1 => ...
  when EX2 => ...
  when others => ...
finally
...
end;

This would allow programmers to handle common cleanup operations that would otherwise have to be duplicated in every exception case.  This is mostly useful if the code was going to re-raise the exception or return control to the caller in the exception handler.  Control would be returned to the caller after the 'finally' block if it exists otherwise the program flow behaves as it does now.

These three examples, 'next', loop...'then'...end, 'finally', all allow the programmer to produce constructs without having to introduce extraneous variables, blocks, or sub-routines to track state which, in my opinion, can often make the code more difficult to read.

Re: stopping a loop iteration without exiting it

[J-P. Rosen]

Le 06/01/2018 à 01:26, Matt Borchers a écrit :
> begin
> ...
> exception
>   when EX1 => ...
>   when EX2 => ...
>   when others => ...
> finally
> ...
> end;
> 
> This would allow programmers to handle common cleanup operations that would otherwise have to be duplicated in every exception case.
Actually, it is possible (ever since Ada 83!) to have a common part for
all exception handlers, and then different handlings according to the
exception:

exception
   when others =>
      begin
         Common_Part;
         raise;
      exception
         when EX1 => ...
         when EX2 => ...
         ...
      end;
end

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: stopping a loop iteration without exiting it

[Matt Borchers]

On Saturday, January 6, 2018 at 5:04:08 PM UTC-5, J-P. Rosen wrote:
> Le 06/01/2018 à 01:26, Matt Borchers a écrit :
> > begin
> > ...
> > exception
> >   when EX1 => ...
> >   when EX2 => ...
> >   when others => ...
> > finally
> > ...
> > end;
> > 
> > This would allow programmers to handle common cleanup operations that would otherwise have to be duplicated in every exception case.
> Actually, it is possible (ever since Ada 83!) to have a common part for
> all exception handlers, and then different handlings according to the
> exception:
> 
> exception
>    when others =>
>       begin
>          Common_Part;
>          raise;
>       exception
>          when EX1 => ...
>          when EX2 => ...
>          ...
>       end;
> end
> 
> -- 
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr

Interesting, but to get the common part to execute AFTER the exception handling looks very strange and begs for a better solution that to re-raise the exception in the first line of the exception handler.

exception
   when others =>
      begin
         raise;
      exception
         when EX1 => ...
         when EX2 => ...
         ...
      end;
      Common_Part;
end;

Re: stopping a loop iteration without exiting it

[Randy Brukardt]

"Matt Borchers" <mattborchers@gmail.com> wrote in message 
news:7b8a1da2-c405-4cbc-9c0b-1fef804c9239@googlegroups.com...
> I would like to also put my voice in for a 'next [when condition]' 
> statement.  It is also
> my opinion that in some cases it is more readable.  I would avoid 
> 'continue' only
> because it is a C term.  The use of 'goto' in a loop to act like a next by 
> jumping to
> the END of the loop seems more like a hack and I agree with the sentiment 
> that it
> adds more confusion for the reader.

A "next" statement would require making "next" a reserved word, which would 
be wildly incompatible, "Next" subprograms are very common (they exist in 
the containers and the iterator interface).

A "continue" statement would be an incompatibility for some, but a "next" 
statement would be an incompatibility for almost everyone. As such, there is 
no chance of using that syntax.

                                     Randy.

Re: stopping a loop iteration without exiting it

[Mehdi Saada]

If order is signifiant, how about putting the common part in a procedure, and calling it after or before the specific part, in each of the "whens" ?

Re: stopping a loop iteration without exiting it

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> If order is signifiant, how about putting the common part in a
> procedure, and calling it after or before the specific part, in each
> of the "whens" ?

Of course, but it adds noise (the declaration of the procedure) and you
might easily forget to put the call in on one of the branches
(especially if added later).

Re: stopping a loop iteration without exiting it

[Matt Borchers]

On Sunday, January 7, 2018 at 6:33:42 AM UTC-5, Mehdi Saada wrote:
> If order is signifiant, how about putting the common part in a procedure, and calling it after or before the specific part, in each of the "whens" ?

Yes, one could do that.  My first post in this thread wasn't about how to code within the bounds of the current syntax.  Rather it was how a programmer 'might' avoid creating extraneous variables and sub-programs to overcome these types of issues when alternative syntactical forms exist.  Don't get me wrong though, I love Ada.

Re: stopping a loop iteration without exiting it

[Micah Waddoups]

On Wednesday, January 3, 2018 at 9:54:36 AM UTC-7, Mehdi Saada wrote:
> Is there a way to tell to ignore the remaining of a loop ? Like an exit statement, but instead of quiting the loop, it would go to the next iteration.
> Can we do this except with a recursive structure ?

Of all the things I've read in this post, I think the closest thing to the ideals and standards of Ada is the `goto My_Loop` idea.  Making any named structure flow control accessible with the goto statement, only specifying the next loop of such, and exiting any inner loops in the process reduces code written in some cases and more importantly, it is very clear where the decision to exit/continue-next is made and exactly which loop is being jumped to the next iteration.  This short-circuit behavior is similar to the `and then` and `or else` convention used in Boolean condition testing.

Unfortunately, this is not part of the Ada standard yet, and any changes/additions to the standard are not done lightly, since the real working world relies on the long-term maintainability and robust nature of Ada.  Therefore, it may never become part of the standard.  I personally hope that the goto <Named_Structure> convention is added, or if it is not, that some equivalent readability improvement is at least considered.  Even so, the main problem that probably prevented it from being added the first time it was suggested is that it stops a `for` loop, which is for the sake of perfect readability and predictability statically set to the range it is given.  Exiting is only very helpful and meaningful when a plain or named loop is used and it would be the same with the goto convention.  Since `goto` with labels is strongly discouraged, there is a subtle barrier of established practices and lint-like tools to repurposing 'goto' when the over-all improvement is mostly trivial.

These are my thoughts, and as a bit of a purist, I do wish for the goto convention to be added, but I also respect the reasons it may never be.

Re: stopping a loop iteration without exiting it

[Simon Wright]

Micah Waddoups <micahwelf@gmail.com> writes:

> On Wednesday, January 3, 2018 at 9:54:36 AM UTC-7, Mehdi Saada wrote:
>> Is there a way to tell to ignore the remaining of a loop ? Like an
>> exit statement, but instead of quiting the loop, it would go to the
>> next iteration.
>> Can we do this except with a recursive structure ?
>
> Of all the things I've read in this post, I think the closest thing to
> the ideals and standards of Ada is the `goto My_Loop` idea.  Making
> any named structure flow control accessible with the goto statement,
> only specifying the next loop of such, and exiting any inner loops in
> the process reduces code written in some cases and more importantly,
> it is very clear where the decision to exit/continue-next is made and
> exactly which loop is being jumped to the next iteration.  This
> short-circuit behavior is similar to the `and then` and `or else`
> convention used in Boolean condition testing.

It seems to me that some sensible naming conventions could do the job
quite well without changing the language.

   Foo : for J in 1 .. 10 loop
      if J = 5 or J = 6 then
         goto Continue_Foo;
      end if;
      K := K + J;
   <<Continue_Foo>>
   end loop Foo;

(I wanted to write <<Foo>> but no)

NB! I would never use a label in so small a context as this! Imagine
lots of checks and lots of code to skip.

Or perhaps <<Next_Foo>>, depending on how much one likes the C
'continue'.

Re: stopping a loop iteration without exiting it

[Robert Eachus]

I probably shouldn't wake up this topic, and that is not my intent.  Just to bring up some history.  When the original ANSI standarization was going on, Pat Prange and I were supporting/maintaining a program called LALR on Multics. LALR would generate LALR(k)--look ahead left-to-right with k symbol lookahead--grammars.  It would generate a (very compact) set of tables, and (from source with embedded CFG (context free grammar) productions which defined the LALR(k) grammar.  We used it for a compiler that started out as GREEN, and evolved into a subset of Ada. (No tasking, and restrictions on generics.)

Robert Dewar preferred LL(1) grammars for Ada compilers since they allowed for better syntax error recovery.   LALR had a neat recovery method which required some fairly tiny tables (less than a hundred 32 or 36 bit words long).  The tables were generated along with the rest of the grammar tables, and were used for several Multics compilers, including the PL/I compiler and MRDS the Multics relational database. Anyway...

If you are going to use a program that needs to generate code containing and using finite state machine (FSM)* tables, you need to have gotos.  So they are necessary in Ada. Neither Robert Dewar or I ever found a use other than implementing FSMs and PDAs that required gotos--all the logic constructs argued above, whether simple or complex, can be turned into FSMs and implemented by a FSM tool.  Not that I recommend it for the simple cases.  For a lexical scanner?  Your choice. For complex flight control software?  The time spent by the avionics designers working over those tables will make the coding effort seem trivial.

* Technically, a parser generator tool generates a pushdown automaton PDA).  This is an FSM with a stack, and certain inputs cause pushing the current state on the stack, or processing the current CFG production then popping the stack. Pushdown automata can recognize any deterministic language with a context free grammar, but most tools are restricted to produce smaller and faster compilers.  (Doesn't cause any grief for language designers.  As long as the language is deterministic (not ambiguous) you can choose your tool.  Early's Algorithm will parse any CFG, but it sometimes takes time O(n^3) where n is the length of the input.  Most good grammars result in parsers which run in O(n log2 n) time or some such.  LL(1) grammars are also known as recursive descent grammars.  Most compiler programmers don't think about what they are writing as a PDA.

Oh, and regular expressions (RE), which are often used to describe the lexical symbols can be parsed without a stack--and again specialized tools make things much faster.