Ichbiah 2022 compiler mode

Ichbiah 2022 compiler mode

[Kevin Chadwick]

I guess this is a very subjective question.

A number of Ada users have expressed that they would rather Ada was simpler
 whilst others desire more features.

I appreciate Ada 83 portability but also like a lot of modern Ada features.

Out of interest. Could anyone help me with what an Gnat or other compiler
 Ichbiah_2022_Mode might look like. Perhaps it might be possible to use
 pragmas to get an estimated mode of what features he might keep or drop.

I can continue research but currently I do not have the details of his
 objections to Ada 95 and how those may have continued through to today is
 perhaps a nuanced question.

What do you think Ichbiah would jettison from Ada 2022? All comments
 welcome.

-- 
Regards, Kc

Re: Ichbiah 2022 compiler mode

[Jeffrey R.Carter]

On 2024-09-05 13:52, Kevin Chadwick wrote:
> 
> I can continue research but currently I do not have the details of his
> objections to Ada 95 and how those may have continued through to today is
> perhaps a nuanced question.

Ichbiah's objections to Ada 95 are in 
https://web.elastic.org/~fche/mirrors/old-usenet/ada-with-null.

-- 
Jeff Carter
"[T]he language [Ada] incorporates many excellent structural
features which have proved their value in many precursor
languages ..."
C. A. R. Hoare
180

Re: Ichbiah 2022 compiler mode

[Bill Findlay]

On 5 Sep 2024, Jeffrey R.Carter wrote
(in article <vbcccj$a13q$1@dont-email.me>):

> "[T]he language [Ada] incorporates many excellent structural
> features which have proved their value in many precursor
> languages ..."
> C. A. R. Hoare

And he continued:

"one can look forward to a rapid and widespread improvement in programming 
practice,
both from those who use the language and from those who study its concepts 
and structures."

I am familiar with this, as one of the authors of the book
that contains that foreword. 8-)
-- 
Bill Findlay

Re: Ichbiah 2022 compiler mode

[Kevin Chadwick]

>> 
>> I can continue research but currently I do not have the details of his
>> objections to Ada 95 and how those may have continued through to today is
>> perhaps a nuanced question.
>
>Ichbiah's objections to Ada 95 are in 
>https://web.elastic.org/~fche/mirrors/old-usenet/ada-with-null.

Thank you

-- 
Regards, Kc

Re: Ichbiah 2022 compiler mode

[Kevin Chadwick]

>> I can continue research but currently I do not have the details of his
>> objections to Ada 95 and how those may have continued through to today is
>> perhaps a nuanced question.
>
>Ichbiah's objections to Ada 95 are in 
>https://web.elastic.org/~fche/mirrors/old-usenet/ada-with-null.

What does this mean? 

"elimination of accuracy constraints in subtypes"

-- 
Regards, Kc

Re: Ichbiah 2022 compiler mode

[Jeffrey R.Carter]

On 2024-09-05 15:49, Bill Findlay wrote:
> On 5 Sep 2024, Jeffrey R.Carter wrote
> (in article <vbcccj$a13q$1@dont-email.me>):
> 
>> "[T]he language [Ada] incorporates many excellent structural
>> features which have proved their value in many precursor
>> languages ..."
>> C. A. R. Hoare
> 
> And he continued:
> 
> "one can look forward to a rapid and widespread improvement in programming
> practice,
> both from those who use the language and from those who study its concepts
> and structures."
> 
> I am familiar with this, as one of the authors of the book
> that contains that foreword. 8-)

That's signature 181.

-- 
Jeff Carter
"[T]he language [Ada] incorporates many excellent structural
features which have proved their value in many precursor
languages ..."
C. A. R. Hoare
180

Re: Ichbiah 2022 compiler mode

[Jeffrey R.Carter]

On 2024-09-05 18:08, Kevin Chadwick wrote:
> 
> What does this mean?
> "elimination of accuracy constraints in subtypes"

See ARM-95 J.3 
(https://www.adaic.org/resources/add_content/standards/95lrm/ARM_HTML/RM-J-3.html), 
Reduced Accuracy Subtypes.

-- 
Jeff Carter
"[T]he language [Ada] incorporates many excellent structural
features which have proved their value in many precursor
languages ..."
C. A. R. Hoare
180

Re: Ichbiah 2022 compiler mode

[Randy Brukardt]

"Kevin Chadwick" <kc-usenet@chadwicks.me.uk> wrote in message 
news:vbc625$at65$1@dont-email.me...
...
> What do you think Ichbiah would jettison from Ada 2022? All comments
> welcome.

My recollection is that he wanted a more complex "class" feature, which IMHO 
would have made Ada more complex, not simpler.

In any case, I can't guess what Ichbiah would have suggested after 40 years 
of experience. (He probably would have moved on to some other language 
anyway, you have to be somewhat resistant to change to stick with a single 
language for your entire career. I seem to resemble that remark... ;-)

What I can do is suggest what an RLB_2022 mode would look like, as I did the 
exercise when we all were cooped up during the early days of the pandemic. 
My philosophy is that Ada has a lot of combinations of features that cause a 
lot of implementation trouble, but which are not very useful. So I want to 
reduce the combinations that cause trouble. I note that every feature is 
useful for something (else it wouldn't be in Ada in the first place). But 
some things are not useful enough for the trouble that they cause. Also note 
that I am not worrying about compatibility with Ada, which is always a 
problem when updating Ada itself.

Here's some highlights off the top of my head:

(1) Simplify the resolution model; essentially everything resolves like a 
subprogram. For instance, objects resolve similarly to enumeration literals. 
This substantially reduces the danger of use clauses (having matching 
profiles and names is less likely than just matching names), and eliminates 
the subtle differences between a constant and a function (they should really 
act the same).

(2) Operator functions have to be primitive for at least one of the types in 
the profile. (Operators in a generic formal part have a pseudo-primitive 
requirement.) That includes renamings. In exchange for that, operators have 
the same visibility as the type (which means they are always directly 
visible when any object of the type is visible). One then can eliminate "use 
type" (since it would literally do nothing).

(3) A number of syntax options are eliminated. Matching identifiers are 
required at the end of subprograms and packages. Initializers are always 
required (<> can be used if default initialization is needed). Keyword 
"variable" is needed to declare variables (we do not want the worst option 
to be the easiest to write, as it is in Ada).

(4) Anonymous types of all sorts are eliminated. For access types, we would 
use aspects to declare properties (static vs. dynamic accessibility, 
"closure" types, etc.). For arrays, see next item.

(5) The array model would be greatly simplified. New Ada users (and old ones 
as well) have a hard time dealing with the fact that the lower bound is not 
fixed in Ada. Additionally, the existing Ada model is very complex when 
private types are involved, with operators appearing long after a type is 
declared. The more complex the model, the more complex the compiler, and 
that means the more likely that errors occur in the compiler. There also is 
runtime overhead with these features. The basic idea would be to provide the 
features of an Ada.Containers.Vector, and no more. Very little is built-in. 
That means that arrays can only be indexed by integers, but that is a good 
thing: an array indexed by an enumeration type is really a map, and should 
use a map interface. So I would add a Discrete_Map to the Ada.Containers 
packages. Bounded_Arrays are a native type (most of the uses of arrays that 
I have are really bounded arrays built by hand).

A side-effect of this model change is to greatly simplify what can be 
written as discriminant-dependent components. Discriminant-dependent arrays 
as we know them are gone, replaced by a parameterized array object that has 
only one part that can change. Much of the nonsense associated with 
discriminant-dependent components disappears with this model.

(6) Static items have to be declared as such (with a "static" keyword rather 
than "constant"). Named numbers are replaced by explicit static constants. 
(I would allow writing Universal_Integer and Universal_Real, so one could 
declare static objects and operations of those types.)

(7) Types and packages have to be declared at library-level. This means that 
most generic instances also have to be declared at library-level. Subtypes, 
objects, and subprograms still can be declared at any nesting level. I make 
this restriction for the following reasons:
    (A) Accessibility checks associated with access types are simplified to 
yes/no questions of library-level or not. The only cases where accessibilty 
checks do any real good is when library-level data structures are 
constructed out of aliased objects. These would still be allowed, but almost 
all of the complication would be gone. Even if the check needs to be done 
dynamically, it is very cheap.
    (B) Tagged types declared in nested scopes necessarily require complex 
dynamic accessibility checks to avoid use of dangling types (that is, an 
object which exists of a type that does not exist).
    (C) Reusability pretty much requires ODTs to be declared in 
library-level packages. Mandating that won't change much for most programs, 
and you'll be happier in the long run if you declare the types in library 
packages in the first place.
    (D) There are a lot of semantic complications that occur from allowing 
packages in subprograms, but this is rarely a useful construct.

(8) Protected types become protected records (that is, a regular record type 
with the keyword "protected"). Primitive operations of a protected record 
type are those that are protected actions. (Entries can be declared and 
renamed as such, they would no longer match procedures, which leads to all 
kinds of nonsense.) This would eliminate the problems declaring helper types 
and especially *hiding* helper types for protected types.
(See the problems we had defining the queues in the Ada.Containers to see 
the problem.) The protected operations would allow the keyword "protected" 
in order to make the subprograms involved explicit.

(9) Strings are not arrays! Strings would be provided by dedicated packages, 
supporting a variety of representations. There would be a Root_String'Class 
that encompasses all string types. (So many operations could be defined on 
Root_String'Class).

(10) Variable-returning functions are introduced. They're pretty similar the 
semantics of anonymous access returns (or the aliased function returns 
suggested by Tucker). This means that a variable can easily be treated as a 
function (and indeed, a variable declaration is just syntactic sugar for 
such a function).

(11) Various obsolete features like representation_clauses, representation 
pragmas, and the ability to use 'Class on untagged private types are 
eliminated or restricted.

There were a couple of areas that I never made up my mind on:

(A) Do we need tasks at all? Parallel and task are very much overlapping 
capabilities. But the parallel model would need substantial changes if we 
were to allow suspension of parallel threads (Ada 2022 does not allow this). 
Suspension seems necessary to support intermittent inputs of any type 
(including interrupts) without wasting resources running busy-wait loops.

(B) Should type conversions be operators or remain as the type name as in 
Ada? A type conversion operator, automatically constructed, would allow 
user-defined types to have the same sort of conversions to numeric and 
string types that the predefined do. But an operator would make conversions 
easier, which is probably the wrong direction for a strongly typed language.

(C) I wanted to simply the assignment model, but my initial attempt did not 
work semantically. I'm not sure that simplification is possible with the Ada 
feature set (I'm sure Bob and Tuck tried to do that when creating Ada 95, 
but they failed). The main issue is that one would like to be able to 
replace discriminant checks on user-defined assignment. (Imagine the 
capacity checks on a bounded vector; Ada requires these to match, but that's 
way too strong; the only problem is if the target capacity cannot hold the 
actual length of the source object. A user-defined replacement would be 
helpful.)

My $20 worth (this was a lot more work than $0.02!!). I probably forgot a 
number of items; my actual document is about 20 pages long.

                   Randy. 

Re: Ichbiah 2022 compiler mode

[Lawrence D'Oliveiro]

On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:

> Keyword "variable" is needed to declare variables (we do not want the
> worst option to be the easiest to write, as it is in Ada).

One language idea I toyed with years ago was that

    «name» : «type»;

declared a variable, while

    «name» : «type» := «value»;

declared a constant. So, no initialization of variables at declaration 
time allowed.

> (10) Variable-returning functions are introduced.

Is this like updater functions in POP-11, or “setf” in Lisp? So you have a 
procedure

    set_var(«var», «new value»)

which is declared to be attached to «var» in some way, such that when you 
write

    «var» := «new_value»

this automatically invokes set_var?

Re: Ichbiah 2022 compiler mode

[Jeffrey R.Carter]

On 2024-09-05 13:52, Kevin Chadwick wrote:
> 
> Out of interest. Could anyone help me with what an Gnat or other compiler
> Ichbiah_2022_Mode might look like.

I have no idea what he would have done. For an idea of what I think a language 
should have, you can look at my informal description of King 
(https://github.com/jrcarter/King).

-- 
Jeff Carter
"My name is Jim, but most people call me ... Jim."
Blazing Saddles
39

Re: Ichbiah 2022 compiler mode

[Nioclás Pól Caileán de Ghloucester]

On Fri, 6 Sep 2024, Jeffrey R.Carter wrote:
"I have no idea what he would have done. For an idea of what I think a 
language should have, you can look at my informal description of King
(https://github.com/jrcarter/King)."

"Error rendering embedded code

Invalid PDF"
said
HTTPS://GitHub.com/jrcarter/King/blob/main/King_Basics_for_Adaists.pdf

"Probably no one will like the language except me."
said
HTTPS://GitHub.com/jrcarter/King

Hmm.

Re: Ichbiah 2022 compiler mode

[Simon Wright]

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

> (A) Do we need tasks at all? Parallel and task are very much
> overlapping capabilities.

I don't think I've ever wanted parallel. Most embedded system tasks are
one-off, aren't they?

Re: Ichbiah 2022 compiler mode

[Niklas Holsti]

On 2024-09-07 0:22, Simon Wright wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> (A) Do we need tasks at all? Parallel and task are very much
>> overlapping capabilities.
> 
> I don't think I've ever wanted parallel. Most embedded system tasks are
> one-off, aren't they?


More and more mebedded systems use multi-core processors and do heavy, 
parallelizable computations. "Parallel" is intended to support that in a 
light-weight way. In a recent discussion with the European Space Agency, 
they expressed interest in using OpenMP for such computations on-board 
spacecraft with multi-core processors, which is an "embedded" context.

Regarding tasks in embedded systems, I agree that most are one-off, but 
I have occasionally also used tens of tasks of the same task type.

I disagree with Randy's view that tasks and "parallel" are much 
overlapping. Tasks are able to communicate with each other, but AIUI 
parallel tasklets are not meant to do that, and may not be able to do 
that. Tasks can have different priorities; tasklets cannot.

Re: Ichbiah 2022 compiler mode

[Nioclás Pól Caileán de Ghloucester]

On Sat, 7 Sep 2024, Niklas Holsti wrote:
"More and more mebedded systems use multi-core processors and do heavy,
parallelizable computations. "Parallel" is intended to support that in a
light-weight way. In a recent discussion with the European Space Agency, they
expressed interest in using OpenMP for such computations on-board spacecraft
with multi-core processors, which is an "embedded" context."


Hei!

Most of the languages which are referred to by
WWW.OpenMP.org/resources/openmp-compilers-tools
facilitate bugs. (The Spark which is referred to thereon is not the 
Ada-related Spark language.)

Re: Ichbiah 2022 compiler mode

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message 
news:vbdk2t$hj0r$6@dont-email.me...
> On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:
...
>> (10) Variable-returning functions are introduced.
>
> Is this like updater functions in POP-11, or "setf" in Lisp? So you have a
> procedure
>
>    set_var(«var», «new value»)
>
> which is declared to be attached to «var» in some way, such that when you
> write
>
>    «var» := «new_value»
>
> this automatically invokes set_var?

No, it is a function that returns a variable, meaning you can assign into 
the function result. If you have:
    function Foo return variable Integer;
then you can use Foo on either side of an assignment:
    Foo := 1;
    Bar := Foo + 1;

Essentially, this idea treats:
    Var : variable Integer;
as syntactic sugar for
    function Var return variable Integer;

The worth of that is two-fold: (1) Objects and functions now resolve the 
same; (2) one can write a function that acts exactly like an object, and 
thus can replace it in all uses.

Note that Ada currently has generalized reference objects and functions that 
return anonymous access types, and both of these act similarly to a variable 
returning function. But neither is quite a perfect match.

                       Randy.

Re: Ichbiah 2022 compiler mode

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:lk3fsvF7aaaU1@mid.individual.net...
...
> I disagree with Randy's view that tasks and "parallel" are much 
> overlapping. Tasks are able to communicate with each other, but AIUI 
> parallel tasklets are not meant to do that, and may not be able to do 
> that. Tasks can have different priorities; tasklets cannot.

I was (of course) presuming that "tasklets" would get those capabilities if 
they were to replace tasks. That's what I meant about "suspension", which is 
not currently allowed for threads in Ada (parallel code is not allowed to 
call potentially blocking operations). If that was changed, then all forms 
of existing task communication would be allowed.

I'm less certain about the value of priorities, most of the time, they don't 
help writing correct Ada code. (You still need all of the protections 
against race conditions and the like.) I do realize that they are a natural 
way to express constraints on a program. So I admit I don't know in this 
area, in particular if there are things that priorities are truly required 
for.

                             Randy.

Re: Ichbiah 2022 compiler mode

[Niklas Holsti]

On 2024-09-12 7:46, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:lk3fsvF7aaaU1@mid.individual.net...
> ...
>> I disagree with Randy's view that tasks and "parallel" are much
>> overlapping. Tasks are able to communicate with each other, but AIUI
>> parallel tasklets are not meant to do that, and may not be able to do
>> that. Tasks can have different priorities; tasklets cannot.
> 
> I was (of course) presuming that "tasklets" would get those capabilities if
> they were to replace tasks. That's what I meant about "suspension", which is
> not currently allowed for threads in Ada (parallel code is not allowed to
> call potentially blocking operations). If that was changed, then all forms
> of existing task communication would be allowed.


Ok, I understand. In that case, what "parallel" adds to the current 
tasking feature is an easy way to create a largish and perhaps 
dynamically defined number of concurrent threads from a "parallel" loop, 
where the threads are automatically created when the loop is started and 
automatically "joined" and destroyed when the loop completes.

I don't mind at all if a future Ada evolution merges tasks and 
"parallel", although it might defeat the easier access to multi-core 
true parallelism that is the goal of the "parallel" extension, AIUI.


> I'm less certain about the value of priorities, most of the time, they don't
> help writing correct Ada code. (You still need all of the protections
> against race conditions and the like.) I do realize that they are a natural
> way to express constraints on a program. So I admit I don't know in this
> area, in particular if there are things that priorities are truly required
> for.


Priorities (or the equivalent, such as deadlines) are absolutely 
required for real-time systems where there are fewer cores than 
concurrent/parallel activities so that the system has to schedule more 
than one such activity on one core.

If Ada did not have tasks with priorities, most of the Ada applications 
I have worked on in my life would have had to avoid Ada tasking and 
retreat to using some other real-time kernel, with ad-hoc mapping of the 
kernels's threads to Ada procedures.

Despite the transition to multi-core processors, I think that there will 
continue to be systems where scheduling is required, because the number 
of concurrent/parallel activities will increase too.

Re: Ichbiah 2022 compiler mode

[J-P. Rosen]

Le 12/09/2024 à 06:46, Randy Brukardt a écrit :
> I was (of course) presuming that "tasklets" would get those capabilities if
> they were to replace tasks. That's what I meant about "suspension", which is
> not currently allowed for threads in Ada (parallel code is not allowed to
> call potentially blocking operations). If that was changed, then all forms
> of existing task communication would be allowed.
Well, tasks are not only for speeding up code. They can be a very useful 
design tool (active objects, independant activities). I think the Ada 
model is clean and simple, I would hate to see it disappear.

> I'm less certain about the value of priorities, most of the time, they don't
> help writing correct Ada code. (You still need all of the protections
> against race conditions and the like.) I do realize that they are a natural
> way to express constraints on a program. So I admit I don't know in this
> area, in particular if there are things that priorities are truly required
> for.
If you had as many cores as tasks, you would not need priorities. 
Priorities are just optimization on how to manage cores when there are 
not enough of them.
I know that people use priorities to guarantee mutual exclusion, and 
other properties. All these algorithms were designed at the time of 
mono-CPU machines, but they fail on multi-cores. Nowadays, relying on 
priorities for anything else than optimization is bad -and dangerous- 
design.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

Re: Ichbiah 2022 compiler mode

[Dmitry A. Kazakov]

On 2024-09-12 09:42, Niklas Holsti wrote:

> I don't mind at all if a future Ada evolution merges tasks and 
> "parallel", although it might defeat the easier access to multi-core 
> true parallelism that is the goal of the "parallel" extension, AIUI.

To me usefulness of "parallel" is yet to be seen, while tasks proved to 
be immensely useful on all architectures available.

> Priorities (or the equivalent, such as deadlines) are absolutely 
> required for real-time systems where there are fewer cores than 
> concurrent/parallel activities so that the system has to schedule more 
> than one such activity on one core.
> 
> If Ada did not have tasks with priorities, most of the Ada applications 
> I have worked on in my life would have had to avoid Ada tasking and 
> retreat to using some other real-time kernel, with ad-hoc mapping of the 
> kernels's threads to Ada procedures.

Right.

> Despite the transition to multi-core processors, I think that there will 
> continue to be systems where scheduling is required, because the number 
> of concurrent/parallel activities will increase too.

Yes.

The law of nature is that any resources becoming available will be 
consumed by the software regardless the purpose of... (:-))

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

Re: Ichbiah 2022 compiler mode

[Niklas Holsti]

On 2024-09-12 12:04, J-P. Rosen wrote:

   [...]

> Well, tasks are not only for speeding up code. They can be a very useful 
> design tool (active objects, independant activities). I think the Ada 
> model is clean and simple, I would hate to see it disappear.

I agree.

>> I'm less certain about the value of priorities, [...]

> Priorities are just optimization on how to manage cores when there are 
> not enough of them.

In some contexts it could be optimization -- for example, to increase 
throughput in a soft real-time system -- but in hard real-time systems 
priorities (or deadlines) are needed for correctness, not just for 
optimizatiion.

> I know that people use priorities to guarantee mutual exclusion, and 
> other properties. All these algorithms were designed at the time of 
> mono-CPU machines, but they fail on multi-cores.

In SW for multi-core systems it can be beneficial to collect tasks that 
frequently interact with each other or with the same single-user 
resources in the same core, and then the mono-core mutual-exclusion 
algorithms like priority ceiling inheritance can be used for that group 
of tasks, while using other algorithms for mutual exclusion between 
tasks running in different cores.

Re: Ichbiah 2022 compiler mode

[Kevin Chadwick]

\r>If Ada did not have tasks with priorities, most of the Ada applications 
>I have worked on in my life would have had to avoid Ada tasking and 
>retreat to using some other real-time kernel, with ad-hoc mapping of the 
>kernels's threads to Ada procedures.
>

Counter intuitively it is possible that this is holding Ada back. A lot of
 Ada code cannot run without some fairly complex runtime support due to
 tasks, protected objects, finalization etc.. Runtimes have to be developed
 for each chip instead of each cpu. Atleast I assume that that is why these
 features are not available to e.g. the light cortex-m33 or cortex-m4 or
 cortex-m0+ runtimes. This requires rewriting code which isn't required with
 equivalent C code such as containers and ip stacks etc.. Even support for
 the Ada interrupt package is missing but it looks like porting that support
 to chips is less work and research.

If you need advanced multi core support then using an OS seems like a more
 suitable situation to be in to me.

-- 
Regards, Kc

Re: Ichbiah 2022 compiler mode

[Niklas Holsti]

On 2024-09-12 15:36, Kevin Chadwick wrote:
> 
>> If Ada did not have tasks with priorities, most of the Ada 
>> applications I have worked on in my life would have had to avoid Ada 
>> tasking and retreat to using some other real-time kernel, with ad-hoc 
>> mapping of the kernels's threads to Ada procedures.
>>
> 
> Counter intuitively it is possible that this is holding Ada back. A lot of
> Ada code cannot run without some fairly complex runtime support due to
> tasks, protected objects, finalization etc.. Runtimes have to be developed
> for each chip instead of each cpu.


True, however an Ada RTS can implement many of the tasking features with 
moderate effort on top of non-Ada real-time kernels such as FreeRTOS, 
VxWorks, etc., as AdaCore have done for some kernels. At least for the 
Ravenscar and Jorvik profiles. AIUI, the processor-specific stuff is 
then mainly in the kernel, not in the RTS.


> If you need advanced multi core support then using an OS seems like a more
> suitable situation to be in to me.


Using a large OS like Linux would not be acceptable for many embedded 
systems. Fortunately the smaller real-time kernels are adding multi-core 
support too.

The great advantage of using the standard Ada tasking feature, special 
syntax and all, is that your embedded Ada program can then be executed 
on a PC or other non-embedded computer, for testing or other purposes, 
tasking and all. It can also be analysed by static-analysis tools such 
as AdaControl for race conditions and other tasking-sensitive issues.

Re: Ichbiah 2022 compiler mode

[Lawrence D'Oliveiro]

On Wed, 11 Sep 2024 23:39:27 -0500, Randy Brukardt wrote:

> "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
> news:vbdk2t$hj0r$6@dont-email.me...
>> On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:
> ...
>>> (10) Variable-returning functions are introduced.
>>
>> Is this like updater functions in POP-11, or "setf" in Lisp?
> 
> No, it is a function that returns a variable, meaning you can assign
> into the function result.

I think an updater function would be more generally useful. Because some 
things you want to update might not (depending on the implementation) live 
independently in an explicit variable. And it seems good not to constrain 
implementations unnecessarily.

Re: Ichbiah 2022 compiler mode

[Nioclás Pól Caileán de Ghloucester]

On Thu, 12 Sep 2024, Kevin Chadwick wrote:
"Counter intuitively it is possible that this is holding Ada back. A lot of
Ada code cannot run without some fairly complex runtime support due to
tasks, protected objects, finalization etc.. Runtimes have to be developed
for each chip instead of each cpu."


A book by Burns and Wellings unsensibly boasts that the demanding runtime 
demands of Ada are an advantage because if you be with them then you be 
with them, whereas as Kevin Chadwick points out - they are not easy to 
make.

Re: Ichbiah 2022 compiler mode

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:lkg1vvF1tp6U1@mid.individual.net...
...
>> Priorities are just optimization on how to manage cores when there are 
>> not enough of them.
>
> In some contexts it could be optimization -- for example, to increase 
> throughput in a soft real-time system -- but in hard real-time systems 
> priorities (or deadlines) are needed for correctness, not just for 
> optimizatiion.

This I don't buy: priorities never help for correctness. At least not 
without extensive static analysis, but if you can do that, you almost 
certainly can do the correctness without depending upon priorities.

I view priorities as similar to floating point accuracy: most people use 
them and get the results they want, but the reason for that is that they got 
lucky, and not because of anything intrinsic. Unless you do a lot of 
detailed analysis, you don't know if priorities really are helping or not 
(and similarly, whether your results actually are meaningful in the case of 
floating point).

Anyway, I don't see any such changes coming to Ada, but rather to some 
separate follow-on language (which necessarily needs to be simpler), and 
thus some things that are sometimes useful would get dropped.

(Different message)
...
> Ok, I understand. In that case, what "parallel" adds to the current 
> tasking feature is an easy way to create a largish and perhaps dynamically 
> defined number of concurrent threads from a "parallel" loop, where the 
> threads are automatically created when the loop is started and 
> automatically "joined" and destroyed when the loop completes.

I think the parallel block is more useful for general tasking. The advantage 
of using parallel structures is that they look very similar to sequential 
structures, and one lets the system do the scheduling (rather than trying to 
figure out an organization manually).

One of the advantages of the model I'm thinking about is that it separates 
concerns such as parallel execution, mutual exclusion, inheritance, 
organization (privacy, type grouping), and so on into separate (mostly) 
non-overlapping constructs. Ada started this process by having tagged types 
a separate construct from packages; you need both to get traditional OOP, 
but you can also construct many structures that are quite hard in 
traditional "one construct" OOP. I think that ought to be done for all 
constructs, and thus the special task and protected constructs ought to go. 
We already know that protected types cause problems with privacy of 
implementation and with inheritance. Tasks have similar issues (admittedly 
less encountered), so splitting them into a set of constructs would fit the 
model.

In any case, this is still a thought experiment at this time, whether 
anything ever comes of it is unknown.

                Randy.




               Randy. 

Re: Ichbiah 2022 compiler mode

[Randy Brukardt]

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message 
news:vbvpmt$esm6$7@dont-email.me...
> On Wed, 11 Sep 2024 23:39:27 -0500, Randy Brukardt wrote:
>
>> "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
>> news:vbdk2t$hj0r$6@dont-email.me...
>>> On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:
>> ...
>>>> (10) Variable-returning functions are introduced.
>>>
>>> Is this like updater functions in POP-11, or "setf" in Lisp?
>>
>> No, it is a function that returns a variable, meaning you can assign
>> into the function result.
>
> I think an updater function would be more generally useful. Because some
> things you want to update might not (depending on the implementation) live
> independently in an explicit variable. And it seems good not to constrain
> implementations unnecessarily.

Unfortunately, "updater" functions don't work with the Ada model of 
components, because you can't tell what to do when a component appears or 
disappears in an assignment. (That's why Ada doesn't allow overloading 
":=".) And composition is very important to Ada -- stand-alone objects are 
pretty rare outside of those for scalar types. I don't think something that 
only worked with stand-alone objects would be very useful (can't use those 
with ODTs, for instance)..

                  Randy.

Re: Ichbiah 2022 compiler mode

[Dmitry A. Kazakov]

On 2024-09-14 08:13, Randy Brukardt wrote:

> I think the parallel block is more useful for general tasking. The advantage
> of using parallel structures is that they look very similar to sequential
> structures, and one lets the system do the scheduling (rather than trying to
> figure out an organization manually).

Tasking is not about scheduling. It is about program logic expressed in 
a sequential form. It is about software decomposition. Parallel 
constructs simply do not do that.

> One of the advantages of the model I'm thinking about is that it separates
> concerns such as parallel execution, mutual exclusion, inheritance,
> organization (privacy, type grouping), and so on into separate (mostly)
> non-overlapping constructs.

To me it is exactly *one* construct: inheritance. You should be able to 
inherit from an abstract protected interface at any point of type 
hierarchy in order to add mutual exclusion:

    type Protected_Integer is new Integer and Protected;

> Ada started this process by having tagged types
> a separate construct from packages;

I see modules and types as unrelated things.

  you need both to get traditional OOP,
> but you can also construct many structures that are quite hard in
> traditional "one construct" OOP. I think that ought to be done for all
> constructs, and thus the special task and protected constructs ought to go.

Constructs yes, they must go. It must be all inheritance. The concepts 
must stay.

> We already know that protected types cause problems with privacy of
> implementation and with inheritance. Tasks have similar issues (admittedly
> less encountered), so splitting them into a set of constructs would fit the
> model.

The problems are of syntactic nature, IMO.

There is an issue with an incomplete inheritance model. You need not 
just complete overriding but also more fine mechanisms like extension in 
order to deal with entry point implementations. The same problem is with 
constructors and destructors, BTW. What should really go is 
Ada.Finalization mess replaced by a sane user construction hooks model 
for all types, class-wide ones included.

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

Re: Ichbiah 2022 compiler mode

[Lawrence D'Oliveiro]

On Sat, 14 Sep 2024 01:18:25 -0500, Randy Brukardt wrote:

> Unfortunately, "updater" functions don't work with the Ada model of
> components, because you can't tell what to do when a component appears
> or disappears in an assignment.

But it’s just syntactic sugar, nothing more. Instead of

    a := obj.get_prop()
    obj.set_prop(a)

(both of which have valid Ada equivalents), you can unify them into

    a:= obj.prop
    obj.prop := a

What difference does writing it differently make?

Re: Ichbiah 2022 compiler mode

[Lawrence D'Oliveiro]

On Sat, 14 Sep 2024 01:13:28 -0500, Randy Brukardt wrote:

> ... priorities never help for correctness.

Concurrent programming was never about correctness, it was about 
efficiency/performance (throughput, latency, whatever is appropriate). And 
priorities are just another part of this.

Re: Ichbiah 2022 compiler mode

[Niklas Holsti]

On 2024-09-14 9:13, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:lkg1vvF1tp6U1@mid.individual.net...
> ...
>>> Priorities are just optimization on how to manage cores when there are
>>> not enough of them.
>>
>> In some contexts it could be optimization -- for example, to increase
>> throughput in a soft real-time system -- but in hard real-time systems
>> priorities (or deadlines) are needed for correctness, not just for
>> optimizatiion.
> 
> This I don't buy: priorities never help for correctness. At least not
> without extensive static analysis, but if you can do that, you almost
> certainly can do the correctness without depending upon priorities.


You misunderstood me; perhaps I was too brief.

I said "hard real-time systems", which means that the program is correct 
only if it meets its deadlines, for which priorities or deadline-based 
scheduling are necessary if there are fewer cores than 
concurrent/parallel activities, and the application has a wide range of 
deadlines and activity execution times.

(To be honest, there is the alternative of using a single thread that is 
manually sliced into small bits, interleaving all the activities 
increment by increment, according to a static, cyclic schedule, but that 
is IMO a horribly cumbersome and unmaintainable design, though 
unfortunately still required in some contexts.)

I believe we agree that priorities should be used for other things, such 
as controlling access to shared data, only if there is a well-defined 
and safe mechanism for it, such as protected objects with priority 
ceilings and priority inheritance on a single core.