What was the rationale for prohibiting constant record components?

Sat, 2006-07-01 at 10:37 -0700, ME wrote:

What I meant was components that can not be changed after the record
components are initialized.
I can not use Record discriminanats because I have a two dimensional
unconstrained array of these records.

You could use "component notation" with a suitable function in Ada 2005,

package rec is

type R is tagged private;

function make(m: INTEGER) return R;
-- `m` is the initial value for the immutable component

function immutable(thing: R) return INTEGER;

private

type R is tagged record
mutable: INTEGER;
data: INTEGER;
end record;

pragma inline(immutable);
end rec;

x: rec.R;
n: INTEGER;
begin
n := x.immutable; -- Ada 2005
x.immutable := n; -- illegal to assign to function result

Sat, 1 Jul 2006 09:25:06 -0700, "ME" <abcdefg@nonodock.netwrote:

>What was the rationale for prohibiting constant record components?.

The e-mail address of the first author seems to be bad and it won't
accept private e-mail. Those who make decisions on preventing Ada from
getting constant record fields don't like e-mail communications with
persons of comp.lang.ada. Eg., where is Eachus, Duff, Dewar, and
beyond the most lengthened tendril, Mr Tucker Taft and less known
'friends'.

[Cyberkit 3 in Windows mapped "nonodock.net" to "a.gtld-servers.net".]

Another address that is probably dud is Mr Carter's "acm.non.spam.org".

+- Craig Carey

Jeffrey R. Carter wrote:

Ada.Text_IPut_Line ("Component is not constant");

You get 3 guesses which string is output, and the 1st 2 don't count.
Clearly, this does not meet the P's interest in components that cannot
be changed after initialization.

Not sure whether it is clear that the P wanted records initialized
twice, as in

A : Rec.R := Rec.Make (1);
begin
A := Rec.Make (2);

To enforce the contract of the constructor function `make` ("call once
for each object") and still not making the records or a component limited
how about this workaround then:

package Rec is

type R is tagged private;

procedure make(m: INTEGER; result: in out R);
-- `m` is the initial value for the immutable component
-- pre: result has not been initialized

function immutable(thing: R) return INTEGER;

private

type R is tagged record
mutable: INTEGER;
data: INTEGER;
identity: PSITIVE'base := 0;
end record;

end Rec;

Imagine a protected Sequence in the body that generates unique
positive values for the .identity part of R. Make raises Program_Error
whenever called with a Result that has .identity /= 0.

A limited component Immutable looks like another option to me.

(Yes, there are no immutable non-limited components other than
discriminants, but possibly there is a solution, sort of,
that works reasonably well even though it takes some space?)

"ME" <abcdefg@nonodock.netwrote in message
news:12aihj2lrjqpc3a@corp.supernews.com

Yes, why not. Anyway , discriminants allow a type of constant component so
the mechanism is possible.

Discriminants are limited to elementary types, so the issues don't come up.
(There are no controlled elementary types.) But it would be very odd to
limit constant components to elementary types; it would appear to users to
be a bug in the language.

So the existence of discriminants don't prove much about the feasibility of
constant record components.

Randy.

Mon, 3 Jul 2006 18:53:30 -0500, "Randy Brukardt" wrote:
>"ME" <abcdefg@nonodock.netwrote in message

>
>So the existence of discriminants don't prove much about the feasibility of
>constant record components.

It seems that implementing constant record fields may be extremely
easy. No new code is generated.

Jim Moore (ie. the official mouthpiece of USA, incl Hawaii) would hint
that IS standards are almost what every man would desire. He and
Mr Leroy seem to achieve incredibly little over very long time
intervals.

I guess that the work involves some non-flag_burning of a NY GPL and
forking up one of the free Adas.

'constant' record fields would not be constant inside of the body of
the package that defines them.

For GNAT, a language formally (in the IBM + France style) INCMPATIBLE
with any IS standard of Geneva, would be willed into place using
(say):
-notdewarmode 3

Isn't it the case that the pale blue at Mr Dewar's website got
darker. I was considering copying and colourizing the website.
I see Duff has write access to GNAT.

university educational standards website was pale blue but junked
that are many months of scandals over lax religious-grade internal
quality (cf Adacore's tardy orced-upon-it approx 2002 decision to
make all discussions secret)L
http://www.ncea.govt.nz/
phone company oversight agency is a bit pale blue (does nothing):

How is Janus coming along ?.

Craig Carey,
NZ ISPs:

Randy,

What was the rationale behind prohibiting constant record components?
"Randy Brukardt" <randy@rrsoftware.comwrote in message
@megapath.net
"ME" <abcdefg@nonodock.netwrote in message
news:12aihj2lrjqpc3a@corp.supernews.com

>Yes, why not. Anyway , discriminants allow a type of constant component
>so
>the mechanism is possible.
>
Discriminants are limited to elementary types, so the issues don't come
up.
(There are no controlled elementary types.) But it would be very odd to
limit constant components to elementary types; it would appear to users to
be a bug in the language.

So the existence of discriminants don't prove much about the feasibility
of
constant record components.

Randy.
--

Craig Carey <research@ijs.co.nzwrites:

Mon, 3 Jul 2006 09:50:31 +0200, "Dmitry A. Kazakov" wrote:
Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.dewrote:
Sat, 1 Jul 2006 09:25:06 -0700, ME wrote:

What was the rationale for prohibiting constant record components?

Initialization and composition issues. Then often it is argued that
discriminants are, though limited.
>
>What were these issues?
>
>You should ask language lawyers. []
>
That is an evasion protecting a mistake.

( has constant record fields. Basically any minor language can
can beat Ada especially in ethics.
^^^^^^^

Quite true. Ada is used in weapon systems. isn't. :-)

Regards -- Markus

"ME" <abcdefg@nonodock.netwrites:

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.dewrote in message
$.dlg@40tude.net
Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
>
>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.dewrote in message
>news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net
Sat, 1 Jul 2006 09:25:06 -0700, ME wrote:

What was the rationale for prohibiting constant record components?

Initialization and composition issues. Then often it is argued that
discriminants are, though limited.
>
>What were these issues?
>
You should ask language lawyers. Consider aggregates:

type Semimutable is record
A : constant Integer := 10;
B : Integer;
end record;

X : Semimutable := (A =20, B =40); -- Constraint_Error?
Y : Semimutable := (A =10, B =40);

It might become tricky when A is a composite or private type. Should it
finalize the component and initialize it *same*? In which sense same? Does
it skip A upon assignments?

Yes, why not. Anyway , discriminants allow a type of constant component so
the mechanism is possible.

If constant record fields are needed, wouldn't it be simpler to just
wrap the whole initializing and assigning into a functional interface?
It would als help to isolate effects of changes if you switch
representation.

Regards -- Markus

"ME" <abcdefg@nonodock.netwrote in message
news:12ak5urrrj6d756@corp.supernews.com
What was the rationale behind prohibiting constant record components?

Well, I'd be tempted to say that they're not "prohibited"; they were never
allowed nor do they naturally appear in the syntax.

But that would be wrong, because very early versions of the language (before
it was called Ada) did indeed have such things. I don't know anything about
them or why they were dropped, as that all happened before I got involved
with Ada.

I can say that the notion that something declared "constant" could in fact
be assigned to in some scope is rather disgusting. I don't think it would
fly.

Randy.

>I can say that the notion that something declared "constant" could in fact
>be assigned to in some scope is rather disgusting.
But it's less disgusting to say
type r is record
fixed : integer range 5 5 := 5;
stuff :
Though I did once fail to use a rep spec on such a record and Ada
cleverly optimized away storage for that record component.

"Jean-Pierre Rosen" <rosen@adalog.frwrote in message
news:p6fi8e.de4.ln@hunter.axlog.fr
Randy Brukardt a :

I can say that the notion that something declared "constant" could in
fact
be assigned to in some scope is rather disgusting. I don't think it
would
fly.

Hmmm Initialization of controlled constants?

After initialization, of course. (Constants are assign-once, logically.
Assign-never would be a problem, because they'd have no value at all in that
case!) And similarly, before finalization (although it shouldn't really be
necessary to clear the finalized result -- but it is often done, and
harmless to do).

Still, allowing the assignment of a name that is declared to be a constant
view at some point between initialization and finalization would be a nasty
change to the language. (Note that it might be possible to assign via a
different name; that's a different issue -- and one that is usually a
programming error.) , "constant" would essentially be
meaningless -- bringing us back to the beginning; if it doesn't mean
anything, why bother with it at all?

Randy.

What I am looking for is a way to read in a values from a file ,assign them
once to records and disallow any future assignment i.e. these "constant
parts of the records represent a structure that I don't want to ever change
during the life of the program (write once and read only afterwards). It
would be similar to a constant declaration but inside of a record. I don't
think that it is disgusting at all.
"Randy Brukardt" <randy@rrsoftware.comwrote in message
@megapath.net
"Jean-Pierre Rosen" <rosen@adalog.frwrote in message
news:p6fi8e.de4.ln@hunter.axlog.fr
>Randy Brukardt a :
>>
>I can say that the notion that something declared "constant" could in
fact
>be assigned to in some scope is rather disgusting. I don't think it
would
>fly.
>>
>Hmmm Initialization of controlled constants?
>
After initialization, of course. (Constants are assign-once, logically.
Assign-never would be a problem, because they'd have no value at all in
that
case!) And similarly, before finalization (although it shouldn't really be
necessary to clear the finalized result -- but it is often done, and
harmless to do).

Still, allowing the assignment of a name that is declared to be a constant
view at some point between initialization and finalization would be a
nasty
change to the language. (Note that it might be possible to assign via a
different name; that's a different issue -- and one that is usually a
programming error.) , "constant" would essentially be
meaningless -- bringing us back to the beginning; if it doesn't mean
anything, why bother with it at all?

Randy.
--

Thu, 2006-07-06 at 22:39 -0700, ME wrote:
What I am looking for is a way to read in a values from a file ,assign them
once to records and disallow any future assignment i.e. these "constant
parts of the records represent a structure that I don't want to ever change
during the life of the program (write once and read only afterwards).

Wouldn't it be an option to declare the public view
of the to-be-constant record subtype limited?

It
would be similar to a constant declaration but inside of a record. I don't
think that it is disgusting at all.
"Randy Brukardt" <randy@rrsoftware.comwrote in message
@megapath.net
"Jean-Pierre Rosen" <rosen@adalog.frwrote in message
news:p6fi8e.de4.ln@hunter.axlog.fr
>Randy Brukardt a crit :
>>
>I can say that the notion that something declared "constant" could in
fact
>be assigned to in some scope is rather disgusting. I don't think it
would
>fly.
>>
>Hmmm Initialization of controlled constants?
>
After initialization, of course. (Constants are assign-once, logically.
Assign-never would be a problem, because they'd have no value at all in
that
case!) And similarly, before finalization (although it shouldn't really be
necessary to clear the finalized result -- but it is often done, and
harmless to do).

Still, allowing the assignment of a name that is declared to be a constant
view at some point between initialization and finalization would be a
nasty
change to the language. (Note that it might be possible to assign via a
different name; that's a different issue -- and one that is usually a
programming error.) , "constant" would essentially be
meaningless -- bringing us back to the beginning; if it doesn't mean
anything, why bother with it at all?

Randy.
>
>
>
>

"ME" <abcdefg@nonodock.netwrote in message
news:12arsrtbe8flpf8@corp.supernews.com
What I am looking for is a way to read in a values from a file ,assign
them
once to records and disallow any future assignment i.e. these "constant
parts of the records represent a structure that I don't want to ever
change
during the life of the program (write once and read only afterwards). It
would be similar to a constant declaration but inside of a record. I don't
think that it is disgusting at all.

The problem with that is that the Initialize routine is just an ordinary
subprogram. That means that either constant components can't be initialized
with them (only directly when the object is created), or you have to have
some rule like "they're read-write in the body", which is what is
disgusting. And remember that Initialize isn't the only routine of this
type; user-defined Read and Input routines also need this property.

There are also issues on complete record assignment of objects with constant
components: what happens if one of the constant components changes? If it
doesn't change (raises Constraint_Error), then you have a discriminant
(effectively); if it does change, then how constant is it?

There may in fact be a solution to these issues, but it has never seemed
important enough to spend the intensive effort needed to find one.

Randy.

"Georg Bauhaus" <bauhaus@futureapps.dewrote in message
news:1152263715.5568.1.camel@localhost
Thu, 2006-07-06 at 22:39 -0700, ME wrote:
>What I am looking for is a way to read in a values from a file ,assign
>them
>once to records and disallow any future assignment i.e. these "constant
>parts of the records represent a structure that I don't want to ever
>change
>during the life of the program (write once and read only afterwards).
>
Wouldn't it be an option to declare the public view
of the to-be-constant record subtype limited?
The record has no discriminants
>
>It
>would be similar to a constant declaration but inside of a record. I
>don't
>think that it is disgusting at all.
>"Randy Brukardt" <randy@rrsoftware.comwrote in message
>@megapath.net
>"Jean-Pierre Rosen" <rosen@adalog.frwrote in message
>news:p6fi8e.de4.ln@hunter.axlog.fr
>>Randy Brukardt a crit :
>>>
>>I can say that the notion that something declared "constant" could
>>in
>fact
>>be assigned to in some scope is rather disgusting. I don't think it
>would
>>fly.
>>>
>>Hmmm Initialization of controlled constants?
>>
>After initialization, of course. (Constants are assign-once, logically.
>Assign-never would be a problem, because they'd have no value at all in
>that
>case!) And similarly, before finalization (although it shouldn't really
>be
>necessary to clear the finalized result -- but it is often done, and
>harmless to do).
>>
>Still, allowing the assignment of a name that is declared to be a
>constant
>view at some point between initialization and finalization would be a
>nasty
>change to the language. (Note that it might be possible to assign via a
>different name; that's a different issue -- and one that is usually a
>programming error.) , "constant" would essentially be
>meaningless -- bringing us back to the beginning; if it doesn't mean
>anything, why bother with it at all?
>>
>Randy.
>>
>>
>>
>>
>

"Georg Bauhaus" <bauhaus@futureapps.dewrote in message
news:44afe7b2$0$29128$9b4e6d93@newsread4.arcor-online.net
ME wrote:
>"Georg Bauhaus" <bauhaus@futureapps.dewrote in message
>news:1152263715.5568.1.camel@localhost
Thu, 2006-07-06 at 22:39 -0700, ME wrote:
What I am looking for is a way to read in a values from a file ,assign
them
once to records and disallow any future assignment i.e. these
"constant
parts of the records represent a structure that I don't want to ever
change
during the life of the program (write once and read only afterwards).
Wouldn't it be an option to declare the public view
of the to-be-constant record subtype limited?
>The record has no discriminants
>
Yes. What I meant has in fact little to do with discriminants.
package P is

type C is limited private;
-- to be the constant part in R -- C ops

type R is record -- cannot be assigned because
but I need R to be assigned
anyway the unconstrained array of records R is private
immutable: C; -- this cannot be assigned either (read only)
other_data: Integer; -- (read/write)
end record;

type Grid is array() of R;

-- etc.

private
type C is record
mutable: Integer; -- can be assigned, e.g. during init
end record;

-- perform initialization in package body, maybe require
-- a suitable callback that reads initial values
--

end P;

ME wrote:
"Georg Bauhaus" <bauhaus@futureapps.dewrote in message


>type C is limited private;
>-- to be the constant part in R -- C ops
>>
>type R is record -- cannot be assigned because
but I need R to be assigned

K. R in nonlimited in the private part and in the body
of the package. A public R operation Update could assign the
record parts that need to be updated from outside. This won't
be as brief as `":=" which doesn't assign to constant parts',
But in return, having an explicit assignment procedure lets you
choose a suitable name for what the assignment is about.

anyway the unconstrained array of records R is private

Good. Sounds like it has an interface of subprograms
already?

>immutable: C; -- this cannot be assigned either (read only)
>other_data: Integer; -- (read/write)
>end record;

Fri, 7 Jul 2006 16:04:13 -0500, "Randy Brukardt"
<randy@rrsoftware.comwrote:

>The problem with that is that the Initialize routine is just an ordinary
>subprogram. That means that either constant components can't be initialized
>with them (only directly when the object is created), or you have to have
>some rule like "they're read-write in the body", which is what is
>disgusting. And remember that Initialize isn't the only routine of this
>type; user-defined Read and Input routines also need this property.
>
>There are also issues on complete record assignment of objects with constant
>components: what happens if one of the constant components changes? If it
>doesn't change (raises Constraint_Error), then you have a discriminant
>(effectively); if it does change, then how constant is it?
>
>There may in fact be a solution to these issues, but it has never seemed
>important enough to spend the intensive effort needed to find one.
>
Randy.

Why is the argument (if any) all behind the single word. Surely you can
undo years of reputation building with that single trick alone.
It seems worse that the word "disgusting" seems to disclose the
existence of a purpose that is a proper topic for inquiry by concealing
the words read-only after this Usenet thread had a sustained failure at
realizing that the word "constant" in the title means read-only rather
than 'constant'.

Brukardt is a notable incompetent at language design; with his black
snout pressed in the back of the polar bear jesery of the great Ada
maritime captains stranded on ice when their ship got frozen in. It all
has to do with money$$; the lax pleasure of besting out the whole
"previous brain-thought" behind a 1-word argument. Voltage levels for
the rest -- collectors of views for re-sale?

I note there can be a lot more parameter passing modes than
Ada's "in" and "out" and "in out".

Eg. record fields currently have the PASCAL style 'in' mode, ie. the
initial value can be modifed.

There is always the ARG contempt for questions technique.

Craig Carey

Fixing renames.

Fri, 14 Jul 2006 20:15:53 +1200, Craig Carey wrote:
Fri, 7 Jul 2006 16:04:13 -0500, "Randy Brukardt" wrote:

>>with them (only directly when the object is created), or you have to have
>>some rule like "they're read-write in the body", which is what is
>>disgusting. And remember that Initialize isn't the only routine of this

A mispelling got partly towards converting jersey into jess, a leather
strap sometimes attached to the leg of a hawk or falcon.

At last check, Ada was not really making any progress at interfacing
with C++, eg. in the following R.R would be written.

generic
Debug : Integer;
package R is
type R'Pkg_Type;-- Prevent an extra pass or "class package" etc.
-- R could be a subtype if tagged for interfacing with C

type R'Pkg_Type (D : DT) is
record
A1 : Integer;
A2 : in Integer;
end record;
-- "in" means that in the view of exterior code the value
-- can't be written to

procedure Get_Val (X : out R, Fname : Str);
end package R

X : R (Dbg =0) (D =D1);

procedure Main is
begin
Get_Val (\ X, Fname ="abc.txt");
X.A2 := 9; -- Syntax error.

The Ada Reference Manual does not use enough words to say what
"renames" should do. GNAT tries to know the memory addresses
finalized inside of the declaration block.

When often encountering the mistake, it seems that a

K : Integer := 1;
while K < 10 loop
declare
A : Integer;
K : constant; -- Lock K down as a constant
E : Element renames A (K);
-- Now it is clear E's address is now known
begin -- K is constant
-- Actually making K constant after the begin would be safer

Craig Carey