From Newsgroup: comp.lang.ada

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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

I am sensible to the complexity vs use balance, and I would easily cope
with the negative consequence of most of the simplifications you propose
(at least those I understand!) but obviously it's hard to be fully aware
of the consequence.

Le 06/09/2024 à 02:03, Randy Brukardt a écrit :

(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).

Why are you considering variables worst than constants?

I don't want the the "worst" option to be the easiest to write, but
neither do I want to put one more keyword in the most common case.

Note that :
1. I have no statistics, but it seems to me that there is more variables
than constants in my code.
2. I say "Useless" from my coder point of view, I dont know if it
simplify the work for compiler or tools implementers.

Lionel
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le 06/09/2024 à 02:03, Randy Brukardt a écrit :

(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).

I suppose that to allows the compiler to discriminate this non sense code

Square (2) := 3;

from the legitimate

List.Index (3) := Item;

you will have to introduce some specific syntax, like Tucker's "aliased function".

I see the huge benefit from a user point of view, but I'm not aware of compiler internals : doesn't the introduction of a second function type increase complexity?



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Lioneldraghi" <lionel.draghi@free.fr> wrote in message news:vk4uee$3lfp0$1@dont-email.me...
...

Le 06/09/2024 � 02:03, Randy Brukardt a �crit :

(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).

Why are you considering variables worst than constants?

I don't want the the "worst" option to be the easiest to write, but
neither do I want to put one more keyword in the most common case.

A lot of "variables" in code actually are only written once. In Ada, those
are better modeled as constants. A constant tells the reader that the value doesn't change during the life of the object, which is easier for analysis (both human and machine).

Secondly, I am assuming that automation is helping to write a lot of code. "One more keyword" is irrelevant in terms of creating code, the only
question is whether it hurts readability. I prefer to have most things
written explicitly (but not to the point of noise, of course). That seems especially true if the code is being written by a program and mostly you are trying to figure out why it doesn't work!

Note that :
1. I have no statistics, but it seems to me that there is more variables than constants in my code.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it simplify the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of the benefits can be gained also by working harder. (That's what C compilers do, after all.)

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Lioneldraghi" <lionel.draghi@free.fr> wrote in message news:vk53gs$3lfp0$2@dont-email.me...

Le 06/09/2024 � 02:03, Randy Brukardt a �crit :

(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).

I suppose that to allows the compiler to discriminate this non sense code

Square (2) := 3;

from the legitimate

List.Index (3) := Item;

you will have to introduce some specific syntax, like Tucker's "aliased function".

I see the huge benefit from a user point of view, but I'm not aware of compiler internals : doesn't the introduction of a second function type increase complexity?

Yes, but Ada already has a bunch of different mechanisms for dealing with objects/functions/exceptions/packages/types. My intent is to collapse those all into one (somewhat more complex) mechanism. The basic idea is that everything resolves a single way, meaning that everything can be overloaded, and there no longer is a semantic difference between:
A : constant T := ...;
and
function A return T is (...);

Whether that really helps remains to be seen, of course. But the goal is to reduce the number of disjoint mechanisms both in the language description
and in the implementation. The hope is then to be able to introduce
additional capabilities on top of a simpler and stronger foundation.

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-12-21 09:14, Randy Brukardt wrote:

"One more keyword" is irrelevant in terms of creating code, the only
question is whether it hurts readability.

More keywords = fewer words that can be used as identifiers

so more keywords makes writing code a little bit harder than fewer keywords.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

I put a lot of effort into making sure that all constants are so declared, because I have the rule that (with certain exceptions) no non-local variables may be referenced from subprograms, but constants may be referenced from anywhere. However, I sometimes have constants that cannot be initialized with a
single expression, resulting in

C : T; -- Constant after initialization

Once C has been initialized, I treat it as a constant. Would your approach allow
the compiler to know that C is really a constant?
--
Jeff Carter
“Anyone who cannot cope with mathematics
is not fully human.”
The Notebooks of Lazarus Long
214
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 21.12.24 09:14, Randy Brukardt wrote:

Note that :
1. I have no statistics, but it seems to me that there is more variables
than constants in my code.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it simplify >> the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of the benefits can be gained also by working harder. (That's what C compilers do, after all.)

What are some compilers offering today? That is, can they find declarations
of variables that could be constants, if so instructed?
I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else. Ada, C++, Java.
(Maybe there are options that I have missed. Or an analysis of a whole
program yields more.)

function testc (b : Boolean) return Integer is
package P is
x : Integer;
end;
begin
if b then
P.x := 42;
end if;
return P.x;
end testc;

int testc(bool b) {
struct {
int x;
} P;
if (b) {
P.x = 42;
}
return P.x;
}

class testc {
class P {
int x;
}
P P;
int $(boolean b) {
if (b) {
P.x = 42;
}
return P.x;
}
}

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 21/12/2024 17:19, G.B. wrote:

On 21.12.24 09:14, Randy Brukardt wrote:

Note that :
1. I have no statistics, but it seems to me that there is more variables >>> than constants in my code.

But how many of them *have* to be variables vs. the number that just are
because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it
simplify
the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of
the
benefits can be gained also by working harder. (That's what C
compilers do,
after all.)

What are some compilers offering today? That is, can they find declarations of variables that could be constants, if so instructed?
I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else.  Ada, C++, Java.
(Maybe there are options that I have missed. Or an analysis of a whole program yields more.)

function testc (b : Boolean) return Integer is
   package P is
     x : Integer;
   end;
begin
  if b then
     P.x := 42;
  end if;
  return P.x;
end testc;

int testc(bool b) {
   struct {
     int x;
   } P;
   if (b) {
     P.x = 42;
   }
   return P.x;
}

class testc {
  class P {
    int x;
  }
  P P;
  int $(boolean b) {
    if (b) {
       P.x = 42;
    }
    return P.x;
  }
}

My understanding is that many compliers will optimise these, and if
trivial numbers will 'optimise' out the variable. Confusing in the debugger!
--
Chris
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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

A lot of "variables" in code actually are only written once. In Ada, those are better modeled as constants. A constant tells the reader that the value doesn't change during the life of the object, which is easier for analysis (both human and machine).

[...]

Agreed. But my understanding is that compilers typically do this kind
of analysis anyway, at least when optimization is enabled. For example,
if I write:

N : Integer := 42;

and later refer to the value of N, if the compiler is able to prove to
itself that N is never modified after its initialization, it can replace
a reference to N with the constant 42 (and possibly fold it into other
constant expressions).

Using "constant" for something that isn't going to be modified is good practice, but I'd say it's for the benefit of the human reader.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le samedi 21 décembre 2024 à 13:26 -0800, Keith Thompson a écrit :

Using "constant" for something that isn't going to be modified is
good
practice, but I'd say it's for the benefit of the human reader.

Exactly the point of Randy. And as Jean-Pierre would say "a program is
written once and read many times" (or something like that).
So having "constant" is a very important point when reading the code
for maintenance. Actually a developer don't care about the compiler,
what is important is the "visible" semantic to the human reader.
--
  Pascal Obry /  Magny Les Hameaux (78)
  The best way to travel is by means of imagination
  http://photos.obry.net
  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long time now.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 22.12.24 13:15, Simon Wright wrote:

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless >> mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long time now.

No effect of either here (gcc-14.1.0). I see a CONSTRAINT_ERROR at run time when using the uninitialized return value, for indexing an array.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> writes:

On 22.12.24 13:15, Simon Wright wrote:

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless >>> mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long
time now.

No effect of either here (gcc-14.1.0). I see a CONSTRAINT_ERROR at run time when using the uninitialized return value, for indexing an array.

I _meant_ to be commenting on

What are some compilers offering today? That is, can they find
declarations of variables that could be constants, if so instructed?

Sorry about that.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message news:vk631h$3vfb4$1@dont-email.me...
...

I put a lot of effort into making sure that all constants are so declared, because I have the rule that (with certain exceptions) no non-local variables may be referenced from subprograms, but constants may be referenced from anywhere.

Precisely. The idea is to encourage use of constants by eliminating the unnatural advantage to writing uninitialized variables. If everything is equally easy/hard to write, then one is more likely to make the best choice for the program.

However, I sometimes have constants that cannot be initialized with a
single expression, resulting in

C : T; -- Constant after initialization

Once C has been initialized, I treat it as a constant. Would your approach allow the compiler to know that C is really a constant?

Not with the approach I was envisioning. Of course, Ada 2022 and beyond already make it possible to initialize a lot more objects (especially with
the introduction of container aggregates), so hopefully it will be less necessary to write things like your example.

Randy.

--
Jeff Carter
"Anyone who cannot cope with mathematics
is not fully human."
The Notebooks of Lazarus Long
214

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message news:vk6tag$4tm1$1@dont-email.me...

On 21.12.24 09:14, Randy Brukardt wrote:

...

Constants do help the compiler generate better code, although a lot of
the
benefits can be gained also by working harder. (That's what C compilers
do,
after all.)

What are some compilers offering today? That is, can they find
declarations
of variables that could be constants, if so instructed?

I was thinking from a code generation perspective, as opposed to static analysis. These are really the same process, but in one case the output is only for a computer, and in the other, the output is for a human. The needs
of those outputs are quite different. I think a lot of compilers do optimizations of constants by discovery, but few compilers do much beyond rudimentary static analysis. I expect that to change, but I may be an
optimist on that...

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114