Ada.Real_Time.Time_Last

Ada.Real_Time.Time_Last

[Simon Wright]

The only use case I can see for this is to allow us to write

   delay until Ada.Real_Time.Time_Last;

at the end of our (Ravenscar) main program. Any other offers?

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-15 16:28 , Simon Wright wrote:
> The only use case I can see for this is to allow us to write
>
>    delay until Ada.Real_Time.Time_Last;
>
> at the end of our (Ravenscar) main program. Any other offers?

Suppose your program has to consider, say, three possible future events, 
at the future times A, B, C : Ada.Real_Time.Time, and must delay until 
the first of those events happens, so you compute a variable Next_Event 
: Ada.Real_Time.Time as the minimum of A, B, and C, and then do "delay 
until Next_Time".

However, if some or all of the events A, B, C might never happen, the 
value Time_Last is a useful placeholder to indicate "this event will 
never happen", because Time_Last is a "neutral element" for the 
operation "minimum of two Time values": minimum (X, Time_Last) = X for 
any Time X.

Many algorithms working with ordered types need a minimal and a maximal 
value of the type, for such uses.

(By the way, my Ravenscar programs always end in an eternal loop, never 
in a delay until Time_Last.)

(By the further way, it is a pity that Ada does not let Ada.Real_Time 
provide the attribute functions Time'Min and Time'Max.)

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

Re: Ada.Real_Time.Time_Last

[Simon Wright]

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

> On 17-11-15 16:28 , Simon Wright wrote:
>> The only use case I can see for this is to allow us to write
>>
>>    delay until Ada.Real_Time.Time_Last;
>>
>> at the end of our (Ravenscar) main program. Any other offers?
>
> Suppose your program has to consider, say, three possible future
> events, at the future times A, B, C : Ada.Real_Time.Time, and must
> delay until the first of those events happens, so you compute a
> variable Next_Event : Ada.Real_Time.Time as the minimum of A, B, and
> C, and then do "delay until Next_Time".
>
> However, if some or all of the events A, B, C might never happen, the
> value Time_Last is a useful placeholder to indicate "this event will
> never happen", because Time_Last is a "neutral element" for the
> operation "minimum of two Time values": minimum (X, Time_Last) = X for
> any Time X.
>
> Many algorithms working with ordered types need a minimal and a
> maximal value of the type, for such uses.

I found that I'd used Time_First to act as a flag (in my implementation
of Timing_Events). Logically I suppose it should be Time_Last.

> (By the way, my Ravenscar programs always end in an eternal loop,
> never in a delay until Time_Last.)

Like

   loop
      null;
   end loop;

? I'd have thought this would prevent the RTS from putting the processor
to sleep, thus wasting energy.

I used to write

   loop
      delay until Clock + Seconds (2);
   end loop;

(which also wastes a little energy) before realizing that (since Time
isn't to be relied on after Time_Last) I might as well delay until
Time_Last.

> (By the further way, it is a pity that Ada does not let Ada.Real_Time
> provide the attribute functions Time'Min and Time'Max.)

I suppose there'd have to be a way of indicating that a private type was
scalar.

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-17 11:20 , Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 17-11-15 16:28 , Simon Wright wrote:
>>> The only use case I can see for this is to allow us to write
>>>
>>>    delay until Ada.Real_Time.Time_Last;
>>>
>>> at the end of our (Ravenscar) main program.

    [snip]

>> (By the way, my Ravenscar programs always end in an eternal loop,
>> never in a delay until Time_Last.)
>
> Like
>
>    loop
>       null;
>    end loop;
>
> ?

No, the environment task becomes one of the working application tasks 
(why waste its stack space?), so more like

    loop
       Wait_For_Trigger_Or_Time;
       Do_Something_Useful;
    end loop;

> I'd have thought this would prevent the RTS from putting the processor
> to sleep, thus wasting energy.

In the only project I've done where the customer asked for sleep mode, 
and we implemented it (that was in C, not Ada) the customer found, 
during their system tests, that periodically entering and leaving sleep 
mode caused supply-voltage transients that coupled into the analog parts 
of the board and perturbed the instrument's ADC. So the SW was changed 
to use an idle loop instead of sleeping. YMMV.

>> (By the further way, it is a pity that Ada does not let Ada.Real_Time
>> provide the attribute functions Time'Min and Time'Max.)
>
> I suppose there'd have to be a way of indicating that a private type was
> scalar.

Long ago, I suggested (on c.l.a) an Ada extension by which a package 
could declare private types using the same classes of types that can be 
used for generic formal types. That would IMO not only be useful for 
programmers, it could formalise some of the informal text in the Ada RM. 
For example, RM A.4.8 defines the type Ada.Direct_IO.Count as

    type Count is range 0 .. implementation defined;

With the suggested extension, this could be written in legal (extended) 
Ada as

    type Count is private range <>;

That form still does not show that Count'First = 0, but with a little 
further extension one could perhaps leave only the upper bound 
unspecified, as in:

    type Count is private range 0 .. <>;

Perhaps it is time for me to revive this proposal...

However, in the case of Ada.Real_Time.Time, it may be too much to 
require that this type should be a scalar one, as it may need a 
combination of range and precision that exceeds that of the largest 
machine scalar.

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

Re: Ada.Real_Time.Time_Last

[AdaMagica]

Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:

> Long ago, I suggested (on c.l.a) an Ada extension by which a package 
> could declare private types using the same classes of types that can be 
> used for generic formal types. That would IMO not only be useful for 
> programmers, it could formalise some of the informal text in the Ada RM. 
> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
> 
>     type Count is range 0 .. implementation defined;
> 
> With the suggested extension, this could be written in legal (extended) 
> Ada as
> 
>     type Count is private range <>;
> 
> That form still does not show that Count'First = 0, but with a little 
> further extension one could perhaps leave only the upper bound 
> unspecified, as in:
> 
>     type Count is private range 0 .. <>;
> 
> Perhaps it is time for me to revive this proposal...
> 
Problem with this is that private types have no predefined operators.

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-18 15:06 , AdaMagica wrote:
> Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:
>
>> Long ago, I suggested (on c.l.a) an Ada extension by which a package
>> could declare private types using the same classes of types that can be
>> used for generic formal types. That would IMO not only be useful for
>> programmers, it could formalise some of the informal text in the Ada RM.
>> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
>>
>>     type Count is range 0 .. implementation defined;
>>
>> With the suggested extension, this could be written in legal (extended)
>> Ada as
>>
>>     type Count is private range <>;
>>
>> That form still does not show that Count'First = 0, but with a little
>> further extension one could perhaps leave only the upper bound
>> unspecified, as in:
>>
>>     type Count is private range 0 .. <>;
>>
>> Perhaps it is time for me to revive this proposal...
>>
> Problem with this is that private types have no predefined operators.

That is a problem with private types in *current* Ada, where a private 
type is fully "opaque". This proposal is meant to remove this problem, 
by letting the programmer provide more information about the private 
type, in the same way as information can now be provided about generic 
formal types, to equip those types with predefined operators that can be 
used in the generic.

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

Re: Ada.Real_Time.Time_Last

[AdaMagica]

Am Samstag, 18. November 2017 14:18:44 UTC+1 schrieb Niklas Holsti:
> On 17-11-18 15:06 , AdaMagica wrote:
> > Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:
> >
> >> Long ago, I suggested (on c.l.a) an Ada extension by which a package
> >> could declare private types using the same classes of types that can be
> >> used for generic formal types. That would IMO not only be useful for
> >> programmers, it could formalise some of the informal text in the Ada RM.
> >> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
> >>
> >>     type Count is range 0 .. implementation defined;
> >>
> >> With the suggested extension, this could be written in legal (extended)
> >> Ada as
> >>
> >>     type Count is private range <>;
> >>
> >> That form still does not show that Count'First = 0, but with a little
> >> further extension one could perhaps leave only the upper bound
> >> unspecified, as in:
> >>
> >>     type Count is private range 0 .. <>;
> >>
> >> Perhaps it is time for me to revive this proposal...
> >>
> > Problem with this is that private types have no predefined operators.
> 
> That is a problem with private types in *current* Ada, where a private 
> type is fully "opaque". This proposal is meant to remove this problem, 
> by letting the programmer provide more information about the private 
> type, in the same way as information can now be provided about generic 
> formal types, to equip those types with predefined operators that can be 
> used in the generic.

Yes - but what do we gain with this new syntax? Is it worth the effort? Which problem does it solve (to rephrase Randy)?

Re: Ada.Real_Time.Time_Last

[Jeffrey R. Carter]

On 11/18/2017 02:18 PM, Niklas Holsti wrote:
>>>
>>>     type Count is private range <>;
> 
> This proposal is meant to remove this problem, by letting the 
> programmer provide more information about the private type, in the same way as 
> information can now be provided about generic formal types, to equip those types 
> with predefined operators that can be used in the generic.

If by that you mean that all the operations available for a generic formal

    type Count is range <>;

are also available for this private type, then Count'First and Count'Last are 
available, and there's nothing private about the type at all. I can't see that 
this buys anything.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-18 16:15 , Jeffrey R. Carter wrote:
> On 11/18/2017 02:18 PM, Niklas Holsti wrote:
>>>>
>>>>     type Count is private range <>;
>>
>> This proposal is meant to remove this problem, by letting the
>> programmer provide more information about the private type, in the
>> same way as information can now be provided about generic formal
>> types, to equip those types with predefined operators that can be used
>> in the generic.
>
> If by that you mean that all the operations available for a generic formal
>
>    type Count is range <>;
>
> are also available for this private type, then Count'First and
> Count'Last are available, and there's nothing private about the type at
> all. I can't see that this buys anything.

Making Count'First and Count'Last available is part of the goal of the 
extension, but the point is that the *expressions* that define their 
values would still be *private*, which means that the user of the type 
cannot (or is not meant to) depend on those expressions. The user can 
access the end result ('First, 'Last) but is not meant to depend on any 
other properties of those expressions.

For various reasons, the developers of the Ada language have seen fit to 
define in the RM some standard, predefined types for which they have 
wanted to state the nature of the type, but not its full definition. For 
example, we have, in package System,

    subtype Any_Priority is Integer range implementation-defined;

The RM could have said,

    type Priority is private;

but then the RM could not have easily expressed the fact that 
Any_Priority is divided into two sub-ranges, Priority and 
Interrupt_Priority, and the RM would have had to provide several 
operations on type Priority, for example relational operators, which are 
now implicitly provided by the parent type Integer.

The purpose of the proposal is to replace the "implementation-defined" 
in such definitions with some formal, legal expression that has the same 
effect. This would make it possible for SW developers to mark such 
"implementation-defined" things as private, while still keeping their 
code in legal Ada rather than semi-formal RM text.

Perhaps the difference is clearer in the case of a private discrete 
type, which could be written (aping the generic formal discrete type 
syntax) as:

    type Item is private (<>);   -- Not current Ada!

This would enable all discrete-type operations on the Item type, but 
would hide (keep private) what sort of discrete type it is, as well as 
the names of the enumeration literals, if it is implemented as an 
enumerated type. The RM defines just such a type in Ada.Interrupts:

    type Interrupt_Id is implementation-defined;

with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an 
implementation-defined discrete type used to identify interrupts."

I agree that this proposal does not provide major benefits, but on the 
other hand it seems to me that it does not require a whole lot of new 
compiler mechanisms -- the information available about such 
"semi-private" types would be the same as the information available 
about generic formal types.

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

Re: Ada.Real_Time.Time_Last

[Dmitry A. Kazakov]

On 2017-11-18 16:24, Niklas Holsti wrote:

> Making Count'First and Count'Last available is part of the goal of the 
> extension, but the point is that the *expressions* that define their 
> values would still be *private*, which means that the user of the type 
> cannot (or is not meant to) depend on those expressions. The user can 
> access the end result ('First, 'Last) but is not meant to depend on any 
> other properties of those expressions.

The proposal should also encompass other cases where information hiding 
principle gets violated, e.g.:

    procedure Foo (I : Integer := 20);

If I don't want to expose the default or when the parameter is a private 
type, I should be able to provide a private value, just like in your case:

    type Count is range 0..<private-value>;

Same applies to the defaults of record type members, BTW.
  --
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-18 18:01 , Dmitry A. Kazakov wrote:
> On 2017-11-18 16:24, Niklas Holsti wrote:
>
>> Making Count'First and Count'Last available is part of the goal of the
>> extension, but the point is that the *expressions* that define their
>> values would still be *private*, which means that the user of the type
>> cannot (or is not meant to) depend on those expressions. The user can
>> access the end result ('First, 'Last) but is not meant to depend on
>> any other properties of those expressions.
>
> The proposal should also encompass other cases where information hiding
> principle gets violated, e.g.:
>
>    procedure Foo (I : Integer := 20);
>
> If I don't want to expose the default or when the parameter is a private
> type, I should be able to provide a private value, just like in your case:
>
>    type Count is range 0..<private-value>;
>
> Same applies to the defaults of record type members, BTW.

Those privacy needs can already be handled by defining the relevant 
values as deferred constants (perhaps modulo some freezing-point 
concerns). Of course this method means that the private constant must be 
given a name; that name may or may not be useful, depending on the case.

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

Re: Ada.Real_Time.Time_Last

[Robert A Duff]

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

> For various reasons, the developers of the Ada language have seen fit to
> define in the RM some standard, predefined types for which they have
> wanted to state the nature of the type, but not its full definition. For
> example, we have, in package System,
>
>    subtype Any_Priority is Integer range implementation-defined;

Yes, and Any_Priority'Last is a static expression.
Would it be static in your proposal?

Programmers need to know the priority range in order to
write pragmas Priority.  So in what sense is this
"private" information?

> This would enable all discrete-type operations on the Item type, but
> would hide (keep private) what sort of discrete type it is, as well as
> the names of the enumeration literals, if it is implemented as an
> enumerated type. The RM defines just such a type in Ada.Interrupts:
>
>    type Interrupt_Id is implementation-defined;
>
> with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an
> implementation-defined discrete type used to identify interrupts."

If Interrupt_Id is an enumeration type (not true for GNAT), you don't
want to hide the names of the interrupts from clients.  If there's a
Gizmo_Device_Interrupt, then clients want to attach handlers to that by
name.

- Bob

Re: Ada.Real_Time.Time_Last

[Niklas Holsti]

On 17-11-19 00:20 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> For various reasons, the developers of the Ada language have seen fit to
>> define in the RM some standard, predefined types for which they have
>> wanted to state the nature of the type, but not its full definition. For
>> example, we have, in package System,
>>
>>    subtype Any_Priority is Integer range implementation-defined;
>
> Yes, and Any_Priority'Last is a static expression.

Hm, I found no explicit statement on that in the RM. I assume it follows 
from the pragma Pure in package System, yes? On the other hand, there is 
an explicit requirement that Default_Bit_Order be static (RM 13.7(35/2)).

> Would it be static in your proposal?

I guess so; in this example, the proposal would only move the actual 
range expression to the private part, so I assume pragma Pure would have 
the same effect (enforce staticness) in the full declaration of the 
semi-private type.

> Programmers need to know the priority range in order to
> write pragmas Priority.  So in what sense is this
> "private" information?

Do you write, unportably:

    pragma Priority (42);

or do you write, as I do:

    Background_Prio : constant Priority := Priority'First;
    One_Herz_Prio   : constant Priority := Background_Prio + 1;
    etc.

and then write

    pragma Priority (Background_Prio);
    etc.?

>> This would enable all discrete-type operations on the Item type, but
>> would hide (keep private) what sort of discrete type it is, as well as
>> the names of the enumeration literals, if it is implemented as an
>> enumerated type. The RM defines just such a type in Ada.Interrupts:
>>
>>    type Interrupt_Id is implementation-defined;
>>
>> with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an
>> implementation-defined discrete type used to identify interrupts."
>
> If Interrupt_Id is an enumeration type (not true for GNAT), you don't
> want to hide the names of the interrupts from clients.  If there's a
> Gizmo_Device_Interrupt, then clients want to attach handlers to that  by
 > name.

The RM defines the package Ada.Interrupts.Names for that (RM C.3.2(26)); 
it contains a set of definitions of constant Interrupt_Id objects, where 
both the names and values of those objects are "implementation-defined". 
This proposal would not change that, but these constants would probably 
become deferred constants, with their actual values in a private part.

For sure, this proposal is not going to remove all 
"implementation-defined" text from the RM. In my mind, that is not the 
goal of the proposal; the goal is to give packages more control over the 
amount of information they publish about their private types. For 
example, I have had cases where I wanted to publish the ability to use a 
private type as an array index type, without revealing much more about 
the type. The RM is only a good source of examples of types which 
should, perhaps, be semi-private in this sense.

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

Re: Ada.Real_Time.Time_Last

[J-P. Rosen]

Le 18/11/2017 à 23:20, Robert A Duff a écrit :
> If Interrupt_Id is an enumeration type (not true for GNAT), you don't
> want to hide the names of the interrupts from clients.  If there's a
> Gizmo_Device_Interrupt, then clients want to attach handlers to that by
> name.
Actually, they are not hidden:
Put (T'Image (T'First));

Or if you want to call a procedure P with the second value of T:
P (T'val (1))

-- 
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: Ada.Real_Time.Time_Last

[Simon Wright]

On Friday, 17 November 2017 21:39:51 UTC, Niklas Holsti  wrote:

> No, the environment task becomes one of the working application tasks 
> (why waste its stack space?), so more like
> 
>     loop
>        Wait_For_Trigger_Or_Time;
>        Do_Something_Useful;
>     end loop;

Very late reply: the reason I haven’t done that is because so far I’ve been 
writing just demo applications: for real, one would at least have something 
like system health monitoring or watchdogging to do.

I’ve discovered that elaboration can use surprising amounts of stack, 
especially if there are containers involved.