Re: Constant record components

Re: Constant record components

[Dmitry A. Kazakov]

On 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.

However the functionality you probably meant is actually not constant
[immutable] components, but rather immutable public views of some
components of mutable [as a whole] records.

If there were record interfaces, that would be possible to have.

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

Re: Constant record components

[ME]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net...
> On 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.
>
> However the functionality you probably meant is actually not constant
> [immutable] components, but rather immutable public views of some
> components of mutable [as a whole] records.
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.
>
> If there were record interfaces, that would be possible to have.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Constant record components

[Georg Bauhaus]

On 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

Re: Constant record components

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> On 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.
> 
> 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
...
> end rec;

    A : Rec.R := Rec.Make (1);
    Y : Integer;

    X : constant Integer := Rec.Immutable (A);
begin
    A := Rec.Make (2);
    Y := Rec.Immutable (A);

    if X = Y then
       Ada.Text_IO.Put_Line ("Component is constant");
    else
       Ada.Text_IO.Put_Line ("Component is not constant");
    end if;

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

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60

Re: Constant record components

[Georg Bauhaus]

Jeffrey R. Carter wrote:


>       Ada.Text_IO.Put_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 OP's interest in components that cannot 
> be changed after initialization.

Not sure whether it is clear that the OP 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: POSITIVE'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?)

Re: Constant record components

[ME]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net...
> On 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?
>
> However the functionality you probably meant is actually not constant
> [immutable] components, but rather immutable public views of some
> components of mutable [as a whole] records.
>
> If there were record interfaces, that would be possible to have.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Constant record components

[Dmitry A. Kazakov]

On Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net...
>> On 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?

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

Re: Constant record components

[Craig Carey]

On Mon, 3 Jul 2006 09:50:31 +0200, "Dmitry A. Kazakov" wrote:
>On Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>> On 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.

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

--

Also fields could be renamed.

type X is record
      P        : Integer;
      Q        : Integer renames P;
   end record;

Re: Constant record components

[M E Leypold]

Craig Carey <research@ijs.co.nz> writes:

> On Mon, 3 Jul 2006 09:50:31 +0200, "Dmitry A. Kazakov" wrote:
> >On Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
> >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> >>> On 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.
> 
> (Oberon has constant record fields. Basically any minor language can
> can beat Ada especially in ethics.
                             ^^^^^^^

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

Regards -- Markus

Re: Constant record components

[ME]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t7hmlpeqyass.1fjxzy2pl8z82$.dlg@40tude.net...
> On Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net...
>>> On 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.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Constant record components

[Randy Brukardt]

"ME" <abcdefg@nonodock.net> wrote 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.

Re: Constant record components

[Craig Carey]

On Mon, 3 Jul 2006 18:53:30 -0500, "Randy Brukardt" wrote:
>"ME" <abcdefg@nonodock.net> wrote 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 ISO 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) INCOMPATIBLE
with any ISO 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.

Our 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 Oct 2002 decision to
make all discussions secret)L
   http://www.ncea.govt.nz/
Our phone company oversight agency is a bit pale blue (does nothing):
   http://www.med.govt.nz/templates/StandardSummary____105.aspx

How is Janus coming along ?.

______________
Craig Carey,
NZ ISPs:  http://www.ispmap.co.nz/searchisp.php
http://www.netguide.co.nz/shopping/directory/index.php?directory=highspeed

Re: Constant record components

[ME]

Randy,

What was the rationale behind prohibiting constant record components?
"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:7bednaJHX_FTMDTZnZ2dnUVZ_uudnZ2d@megapath.net...
> "ME" <abcdefg@nonodock.net> wrote 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.
>
> 

Re: Constant record components

[Randy Brukardt]

"ME" <abcdefg@nonodock.net> wrote 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.

Re: Constant record components

[tmoran]

>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 ObjectAda
cleverly optimized away storage for that record component.

Re: Constant record components

[Jean-Pierre Rosen]

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?

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Constant record components

[Randy Brukardt]

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

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote 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.) Otherwise, "constant" would essentially be
meaningless -- bringing us back to the beginning; if it doesn't mean
anything, why bother with it at all?

                                    Randy.

Re: Constant record components

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> 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).

I've always thought that initializing an object, constant or not, should 
not be considered assignment; more a case of providing a name and 
storage for a value. Perhaps it would be better not to have used the 
assignment symbol for it.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: Constant record components

[ME]

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

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.com> wrote in message 
news:ObSdnQYngMQKEzDZnZ2dnUVZ_oadnZ2d@megapath.net...
> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote 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.) Otherwise, "constant" would essentially be
> meaningless -- bringing us back to the beginning; if it doesn't mean
> anything, why bother with it at all?
>
>                                    Randy.
>
> 

Re: Constant record components

[Georg Bauhaus]

On 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.com> wrote in message 
> news:ObSdnQYngMQKEzDZnZ2dnUVZ_oadnZ2d@megapath.net...
> > "Jean-Pierre Rosen" <rosen@adalog.fr> wrote 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.) Otherwise, "constant" would essentially be
> > meaningless -- bringing us back to the beginning; if it doesn't mean
> > anything, why bother with it at all?
> >
> >                                    Randy.
> >
> > 
> 
> 

Re: Constant record components

[ME]

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message 
news:1152263715.5568.1.camel@localhost...
> On 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.com> wrote in message
>> news:ObSdnQYngMQKEzDZnZ2dnUVZ_oadnZ2d@megapath.net...
>> > "Jean-Pierre Rosen" <rosen@adalog.fr> wrote 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.) Otherwise, "constant" would essentially be
>> > meaningless -- bringing us back to the beginning; if it doesn't mean
>> > anything, why bother with it at all?
>> >
>> >                                    Randy.
>> >
>> >
>>
>>
> 

Re: Constant record components

[Georg Bauhaus]

ME wrote:
> "Georg Bauhaus" <bauhaus@futureapps.de> wrote in message 
> news:1152263715.5568.1.camel@localhost...
>> On 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
     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;

Re: Constant record components

[ME]

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message 
news:44afe7b2$0$29128$9b4e6d93@newsread4.arcor-online.net...
> ME wrote:
>> "Georg Bauhaus" <bauhaus@futureapps.de> wrote in message 
>> news:1152263715.5568.1.camel@localhost...
>>> On 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; 

Re: Constant record components

[Georg Bauhaus]

ME wrote:
> "Georg Bauhaus" <bauhaus@futureapps.de> wrote 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

OK. 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;

Re: Constant record components

[Randy Brukardt]

"ME" <abcdefg@nonodock.net> wrote 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.

Re: Constant record components

[Craig Carey]

On Fri, 7 Jul 2006 16:04:13 -0500, "Randy Brukardt"
 <randy@rrsoftware.com> wrote:

>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

Re: Constant record components

[Craig Carey]

Fixing renames.

On Fri, 14 Jul 2006 20:15:53 +1200, Craig Carey wrote:
>On 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

Re: Constant record components

[ME]

"Craig Carey" <research@ijs.co.nz> wrote in message 
news:i04fb2t4vicb69kl55gsk1surko57g16vc@4ax.com...
>
> Fixing renames.
>
> On Fri, 14 Jul 2006 20:15:53 +1200, Craig Carey wrote:
>>On 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
I like it!
>
>   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 

Re: Constant record components

[M E Leypold]

"ME" <abcdefg@nonodock.net> writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:t7hmlpeqyass.1fjxzy2pl8z82$.dlg@40tude.net...
> > On Sun, 2 Jul 2006 09:13:54 -0700, ME wrote:
> >
> >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >> news:1loq7utmaxvll$.yqsxj5edzqgv.dlg@40tude.net...
> >>> On 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

Re: Constant record components

[Craig Carey]

On Sat, 1 Jul 2006 09:25:06 -0700, "ME" <abcdefg@nonodock.net> wrote:

>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