Mutable parameter of a function (long ago was: Re: What evil would happen?)

Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Alexandre E. Kopilovitch]

Quite long (about a half of year) ago Robert I. Eachus wrote about the rule,
which forbids IN OUT mode for parameters of a function:

>...
> But the rule still won't change, and the reason is not just "politics." 
>   This is just one area of the Ada programming culture that seems to rub 
> foreigners (to Ada) the wrong way.  If you are used to Ada, the current 
> Ada idioms for the few cases that seem to some people to be problems are 
> natural to you.
>
> Since I have done a lot of work on random number generators, the Ada 
> idiom now seems natural to me:
>
> function Random(Gen: in Generator) return ...
>   Local: Generator;
>   for Local'Address use Gen'Address;
> begin
>    ...
> end Random;
>
> Unlike RBKD, I did strongly argue for an in out parameter mode for 
> functions in Ada 9X.  But in doing so I knew that it would be misused 
> more than it would be correctly used.  By now with good implementations 
> of Unbounded_String, most of the real needs for functions with in out 
> parameters have gone away.  You can always declare a procedure with an 
> out parameter of Unbounded_String.  So if the question is reraised I 
> will vote against it.  And I will also vote in favor of a generic that 
> provides the equivalent of Unbounded_String for all array types, 
> including multidimensional array types.

While I was generally satisfied with that particular idiom for the need,
as well as with overall explanations given around it, nevertheless a feeling
remained that some final bit is still missing. And now I came to an idea
about that missing bit, that is, which thing is actually missing, and how it
can be provided.

So, I think that the primary problem with that idiom is that it may be
unknown for a programmer, and the secondary problem is that it isn't always
easily recognizable. In general, the missing thing is a reference point for
this idiom.

Therefore it seems suitable to introduce a pragma for this purpose - to
provide a reference point. This pragma will not affect the code, it will
merely state that the idiom is used for particular parameter of the
subroutine:

  pragma Mutable(subroutine-name, parameter-name); -- or Mutable_Parameter

This pragma checks for two things: 1) the parameter to which it is applied
is in IN mode; 2) the idiom is used for this parameter, that is, there is
a local variable (of appropriate type) in the subroutine, and the Address
attribute for this variable is defined and points to the parameter. If this
check is failed then compiler should complain with long diagnostic message,
which contains these rules (thus effectively explaining the idiom).

What is good with this pragma? Two points: 1) it provides explicit reference
for the idiom - if not within the language manual then at least within a
compiler's documentation (if this pragma will be implementation-defined);
2) this pragma will respond to quite justified Robert Dewar's complaint -
that we can modify a parameter of a function, but can't say that explicitly
in the function's specs.
 
Certainly, this pragma should be optional, that is, the idiom can be used
without this pragma - for obvious compatibility reasons. Although it may be
made required for use of the idiom (that is, for assignment to a variable,
which address is defined by the Address attribute applied to an IN mode
parameter) in subroutines that clearly rely upon Ada0Y features.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> While I was generally satisfied with that particular idiom for the need,
> as well as with overall explanations given around it, nevertheless a feeling
> remained that some final bit is still missing. And now I came to an idea
> about that missing bit, that is, which thing is actually missing, and how it
> can be provided.
> 
> So, I think that the primary problem with that idiom is that it may be
> unknown for a programmer, and the secondary problem is that it isn't always
> easily recognizable. In general, the missing thing is a reference point for
> this idiom.
> 
> Therefore it seems suitable to introduce a pragma for this purpose - to
> provide a reference point. This pragma will not affect the code, it will
> merely state that the idiom is used for particular parameter of the
> subroutine:
> 
>   pragma Mutable(subroutine-name, parameter-name); -- or Mutable_Parameter

First, I see absolutely nothing wrong with a project using this idea, 
even if the compiler doesn't support the pragma.  Second, it would be a 
very useful pragma for portable code that uses "the Rosen trick."

But I have a different worry.  Cases where the Rosen trick are used are 
often for performance reasons, and are almost always equivalent to 
passing an access value instead of a record as the actual parameter.

If the fix for constructors of limited types becomes part of the next 
version of Ada, there will be a better way to deal with the issue.  The 
   Generator type in Ada.Numerics.Float_Random, and 
Ada.Numerics.Discrete_Random is declared limited private, and should be. 
  The same applies to any case where this trick is appropriate.  What 
you will be able to do with constructors for limited private objects in 
Ada 0Y is to make the object created on the stack of the correct size, 
and make the actual parameter type an access type.  Yeah, I know, this 
is a different cheat that works out to the same thing, but assuming the 
compiler supports it, growing the stack to create the actual object and 
doing the necessary initializations will result in something which is 
just as efficient as the Rosen trick but results in an access parameter 
which won't be altered.  (Its target will of course.)

In case this sounds "over the top,"  I currently have a package I use 
that creates per task generators.  Of course, in that case you may need 
to do explicit allocate and free operations to keep the officially per 
task object small, but from a user perspective what is going on in all 
cases is the same.

I certainly don't know what the correct way to deal with the issue of 
access constant parameters is.  I think I would do it by allowing 
constant subtypes for access types.  Maybe in Ada 1Z?

I don't think we know enough to fix that issue yet.  To clarify, there 
are two issues here.  One is that you want some access values to be 
marked as accessing constants, and in other cases you want to restrict 
the use of the designated object.  I feel that there is an elegant 
solution out there, but I don't know how to fill in all the blanks yet.)

Let me give an example (assuming some new syntax where needed:

    type Foo is ...
    type Bar is access Foo;
    subtype CBar is access constant Foo;
    F: Foo;
    CF: constant Foo;
    B: Bar;
    CB: CBar;
    procedure Some_Proc(CBP: in CBar);
    ...
  begin
    B := F'Access;  --okay
    CB := CF'Access; -- no problem
    B := CF'Access; -- illegal?
    CB := F'Access; -- should be okay?
    B := CB; -- illegal, or a run-time check?
    CB := B; -- should be okay.
    Some_Proc(B); --should be okay, but...
  ...
    procedure Some_Proc(CBP: in CBar) is
    ...
    begin
      CBP.Some_Comp := New_Value; -- must be illegal.
      ...
    end Some_Proc;

Just too many question marks in that prototype.  I'd want to prototype 
this and try to fill in the blanks, but only after some of the bigger 
pieces of Ada 0Y have been frozen.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Alexandre E. Kopilovitch wrote:
> 
>> While I was generally satisfied with that particular idiom for the need,
>> as well as with overall explanations given around it, nevertheless a
>> feeling remained that some final bit is still missing. And now I came to
>> an idea about that missing bit, that is, which thing is actually missing,
>> and how it can be provided.
>> 
>> So, I think that the primary problem with that idiom is that it may be
>> unknown for a programmer, and the secondary problem is that it isn't
>> always easily recognizable. In general, the missing thing is a reference
>> point for this idiom.
>> 
>> Therefore it seems suitable to introduce a pragma for this purpose - to
>> provide a reference point. This pragma will not affect the code, it will
>> merely state that the idiom is used for particular parameter of the
>> subroutine:
>> 
>>   pragma Mutable(subroutine-name, parameter-name); -- or
>>   Mutable_Parameter
> 
> First, I see absolutely nothing wrong with a project using this idea,
> even if the compiler doesn't support the pragma.  Second, it would be a
> very useful pragma for portable code that uses "the Rosen trick."

No, it is better never use tricks. The Rosen trick is in general an ability
for an object to identify itself in all context, even in ones stating
something opposite about it. That is an extremely dangerous thing, which
breaks substitutability and so the contract. Is this the motivation for
exposing this potential contract violation to code maintainer using a
pragma? But that would by no means solve the problem. It would make things
only worse. It would say, look, this is an in-parameter, but wait, that was
just joking, because, here is a pragma, carefully hidden somewhere else,
that states the opposite.

> But I have a different worry.  Cases where the Rosen trick are used are
> often for performance reasons, and are almost always equivalent to
> passing an access value instead of a record as the actual parameter.
> 
> If the fix for constructors of limited types becomes part of the next
> version of Ada, there will be a better way to deal with the issue.  The
>    Generator type in Ada.Numerics.Float_Random, and
> Ada.Numerics.Discrete_Random is declared limited private, and should be.
>   The same applies to any case where this trick is appropriate.  What
> you will be able to do with constructors for limited private objects in
> Ada 0Y is to make the object created on the stack of the correct size,
> and make the actual parameter type an access type.  Yeah, I know, this
> is a different cheat that works out to the same thing, but assuming the
> compiler supports it, growing the stack to create the actual object and
> doing the necessary initializations will result in something which is
> just as efficient as the Rosen trick but results in an access parameter
> which won't be altered.  (Its target will of course.)

Yes, this would be much better than the Rosen trick, for the reasons I
mentioned above. But I do not think that people will be happy with buzzing
'Access, aliased, 'Unchecked_Access all over the program. Hopefully this
would errode the position of purists, maybe.

> In case this sounds "over the top,"  I currently have a package I use
> that creates per task generators.  Of course, in that case you may need
> to do explicit allocate and free operations to keep the officially per
> task object small, but from a user perspective what is going on in all
> cases is the same.
> 
> I certainly don't know what the correct way to deal with the issue of
> access constant parameters is.  I think I would do it by allowing
> constant subtypes for access types.  Maybe in Ada 1Z?

That should be for *all* types then! For example:

type Object is ...;
subtype Read_Only is constant Object;

But better to provide all theoretically possible variants of subtypes. That
is:

1. in-subtype (= constant = in: no inout, out operations allowed =
specialization)

2. inout-subtype (= what we presently have)

3. out-subtype (= no in, inout operations = generalization)

Then something should be done with two keywords for the *same* thing. I mean
"constant" and "in".

> I don't think we know enough to fix that issue yet.  To clarify, there
> are two issues here.  One is that you want some access values to be
> marked as accessing constants, and in other cases you want to restrict
> the use of the designated object.

What is the difference? Or you mean to go further, and additionally to
support operation disallowing:

type Ball is ...;
procedure Spin (X : in out Game'Class; Y : Ball);

subtype Plain_Ball is Object;
procedure Spin (X : in out Game'Class; Y : Plain_Ball) is null;

> I feel that there is an elegant
> solution out there, but I don't know how to fill in all the blanks yet.)

Interface inheritance for all types is one. You inherit interface of an
access type and implement it in some different way, for example, by making
all mutators illegal.

> Let me give an example (assuming some new syntax where needed:
> 
>     type Foo is ...
>     type Bar is access Foo;
>     subtype CBar is access constant Foo;
>     F: Foo;

F : aliased Foo; -- I suppose

>     CF: constant Foo;

CF : constant aliased Foo;

There is a problem with renamings. Presently

CF : Foo renames Read_Foo (Stream);

breaks the contract! The result is not Foo, but in fact, constant Foo. This
is in breach with the concept of constant/in subtypes. It should be

CF : constant Foo renames Read_Foo (Stream);

But what to do with the backward compatibility?

>     B: Bar;
>     CB: CBar;
>     procedure Some_Proc(CBP: in CBar);
>     ...
>   begin
>     B := F'Access;  --okay
>     CB := CF'Access; -- no problem
>     B := CF'Access; -- illegal?

It is contradictory! Presently in Ada substitutability errors for the
predefined subtypes (in, inout, constant etc) are statically checkable and
the code with such errors is illegal. At the same time for the user-defined
subtypes these errors are subject of run-time checks and thus the code is
legal. IF "constant" becomes a user-defined subtype, then what to do with
this? It is a real problem, I see no good solution of. For example, if we
would make that all statically checkable violations illegal, then this
would break a lot of existing code.

>     CB := F'Access; -- should be okay?

Yes.

>     B := CB; -- illegal, or a run-time check?

Same as B := CF'Access;, we have a difficult problem here.

>     CB := B; -- should be okay.
>     Some_Proc(B); --should be okay, but...
>   ...
>     procedure Some_Proc(CBP: in CBar) is
>     ...
>     begin
>       CBP.Some_Comp := New_Value; -- must be illegal.

Yes. But where you see any problem? When B is passed to Some_Proc it is
*converted* to CBar. That is.

>       ...
>     end Some_Proc;
> 
> Just too many question marks in that prototype.  I'd want to prototype
> this and try to fill in the blanks, but only after some of the bigger
> pieces of Ada 0Y have been frozen.

IMO it would be difficult to make it in a consistent way without reviewing
the ADT model in Ada. But the time will come, I hope.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> No, it is better never use tricks. The Rosen trick is in general an ability
> for an object to identify itself in all context, even in ones stating
> something opposite about it. That is an extremely dangerous thing, which
> breaks substitutability and so the contract. Is this the motivation for
> exposing this potential contract violation to code maintainer using a
> pragma? But that would by no means solve the problem. It would make things
> only worse. It would say, look, this is an in-parameter, but wait, that was
> just joking, because, here is a pragma, carefully hidden somewhere else,
> that states the opposite.

As long as the use does comply with the ADT model it doesn't bother me. 
  This is certainly the case with a random number generator.  The model 
is that calling Random uses the generator but doesn't modify it.  There 
are other operations in the random number package that do change the 
generator state, and do have the correct (in out) interface.  (Yes, I 
know that the call really does change some hidden values in the 
generator, but that is equivalent to having a pointer in the generator, 
and changing values in the target of the pointer.

But if I did have the pragma available, I'd put it in the private part...

> IMO it would be difficult to make it in a consistent way without reviewing
> the ADT model in Ada. But the time will come, I hope.

Sort of my point.  It would be nice to "improve" Ada with constant 
subtypes.  But there are a lot more useful things to do first, then see 
if they fit.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> No, it is better never use tricks. The Rosen trick is in general an
>> ability for an object to identify itself in all context, even in ones
>> stating something opposite about it. That is an extremely dangerous
>> thing, which breaks substitutability and so the contract. Is this the
>> motivation for exposing this potential contract violation to code
>> maintainer using a pragma? But that would by no means solve the problem.
>> It would make things only worse. It would say, look, this is an
>> in-parameter, but wait, that was just joking, because, here is a pragma,
>> carefully hidden somewhere else, that states the opposite.
> 
> As long as the use does comply with the ADT model it doesn't bother me.
>   This is certainly the case with a random number generator.  The model
> is that calling Random uses the generator but doesn't modify it.

I would object that to use a generator = to modify it (its state), so it
does not comply. If the parameter is a handle to some other object, as it
actually is, because of the Rosen trick, then that should be exposed in the
interface:

function Random (Gen : access Generator) return ...;

IMO the best would be:

procedure Random (Gen : in out Generator) return ...; -- Alas, not Ada!

> There
> are other operations in the random number package that do change the
> generator state, and do have the correct (in out) interface.  (Yes, I
> know that the call really does change some hidden values in the
> generator, but that is equivalent to having a pointer in the generator,
> and changing values in the target of the pointer.
> 
> But if I did have the pragma available, I'd put it in the private part...

The point is that the code reader should see that the random generator is
not a pure function of its argument. This has to be seen immediately from
the specifications, not from a speculation "how-I-would-implement-that".
This is why either the parameter has to be an access or an in-out. Anything
other is wrong, IMO. Similarly the way the operations on File_Type were
declared is IMO wrong!

BTW, this is an example how one error leads to another. The first error was
the design fault of Ada 83, that we had no *procedures* (not functions!)
with return values. The consequent error was to allow access parameters for
functions in Ada 95. The result is completely misleading. Functions
*openly* have side effects, but still have no in-out parameters, forcing
programmers to use pointers (and thus aliased objects).

>> IMO it would be difficult to make it in a consistent way without
>> reviewing the ADT model in Ada. But the time will come, I hope.
> 
> Sort of my point.  It would be nice to "improve" Ada with constant
> subtypes.  But there are a lot more useful things to do first, then see
> if they fit.

I think it would be easier just to add anonymous access-to-constant 
subtypes, and not to try to touch user-defined, named constant subtypes.
The later could be very difficult. One more example:

type X is new Ada.Finalization.Controlled with private;
procedure Initialize (Object : in out X);
procedure Finalize (Object : in out X);

subtype No_No is constant X;

A : No_No; -- Should Initialize raise Constraint_Error, else?
           -- In which contexts Finalize can be called?

This may lead to C++-like nasty rules about special constructor/destructor
contexts etc.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> BTW, this is an example how one error leads to another. The first error was
> the design fault of Ada 83, that we had no *procedures* (not functions!)
> with return values. The consequent error was to allow access parameters for
> functions in Ada 95. The result is completely misleading. Functions
> *openly* have side effects, but still have no in-out parameters, forcing
> programmers to use pointers (and thus aliased objects).

So what your point here - do you mean that the best way was to provide an
opportunity for procedures to return value, and then either forbid access
parameters for functions entirely or at least limit them to access-constant
only?

If so, what is your guess, why that was not happened - neither in Ada 83 nor
much later - in Ada 95? It was so simple to do (for example, that may be done
introducing RETURN mode for a parameter of a procedure), and in fact there
is a workaround for that in GNAT - implementation-defined pragma (which first
appeared in DEC Ada compiler, I think). This matter certainly was not
overlooked by the language designers - there were discussions around that
matter (you can see them on AdaIC website) - although they apparently
concentrated on another way of dealing with the issue - IN OUT mode for
functions.

You probably don't think that Ada 83/95 designers were stupid, and before
Ada 95 there was substantial experience with Ada 93 - so why they did not
went that way? They probably had some arguments against it. Do you think that
those arguments were invalid even then? Or you think that they may be valid
in 80th and in the first half of 90th, but are dead now?

And what I'd like to add here is that those language designers had (and have)
one very important thing that you and I have not: real data. We can guess what
is error-prone, dangerous etc., but this is only guess, based mostly on our
own experience and imagination and on very limited observation; while they had
(and have) large customer base, they deal with actual cases and error reports,
and see large amount of code produced by real users; so they can *know* what
is really error-prone, dangerous, confusing etc., at least in current
circumstances. Therefore any strong judgement from our side about their past
decisions - like "error" - seems inappropriate... we weren't insiders of that
Ada world of the past, and we aren't historians.  So, even you dislike some
decisions and their apparent consequences, let them still be "decisions", not
"errors".




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Dmitry A. Kazakov]

On Mon,  5 Jan 2004 06:17:18 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> BTW, this is an example how one error leads to another. The first error was
>> the design fault of Ada 83, that we had no *procedures* (not functions!)
>> with return values. The consequent error was to allow access parameters for
>> functions in Ada 95. The result is completely misleading. Functions
>> *openly* have side effects, but still have no in-out parameters, forcing
>> programmers to use pointers (and thus aliased objects).
>
>So what your point here - do you mean that the best way was to provide an
>opportunity for procedures to return value, and then either forbid access
>parameters for functions entirely or at least limit them to access-constant
>only?

I meant anonymous access parameters such as:

function Foo (X : access Y) return Z;

Which openly contradicts any possible rationale behind forbidding
in-out parameters.

Alas, there is no anonymous access-to-constant parameters.

As for my point, I have only IF-THEN. If the concept of a function as
a special sort of a pure subroutine with one distinguished side-effect
has to be realized in a language, then that should be made more
consequently than we have it in Ada. Which would also pay off, for
example, by allowing *true* functions in static expressions.

>If so, what is your guess, why that was not happened - neither in Ada 83 nor
>much later - in Ada 95? It was so simple to do (for example, that may be done
>introducing RETURN mode for a parameter of a procedure), and in fact there
>is a workaround for that in GNAT - implementation-defined pragma (which first
>appeared in DEC Ada compiler, I think). This matter certainly was not
>overlooked by the language designers - there were discussions around that
>matter (you can see them on AdaIC website) - although they apparently
>concentrated on another way of dealing with the issue - IN OUT mode for
>functions.
>
>You probably don't think that Ada 83/95 designers were stupid, and before
>Ada 95 there was substantial experience with Ada 93 - so why they did not
>went that way? They probably had some arguments against it. Do you think that
>those arguments were invalid even then? Or you think that they may be valid
>in 80th and in the first half of 90th, but are dead now?

It is a to death beaten issue discussed in c.l.a. over and over again.
Guess why?

>And what I'd like to add here is that those language designers had (and have)
>one very important thing that you and I have not: real data. We can guess what
>is error-prone, dangerous etc., but this is only guess, based mostly on our
>own experience and imagination and on very limited observation; while they had
>(and have) large customer base, they deal with actual cases and error reports,
>and see large amount of code produced by real users; so they can *know* what
>is really error-prone, dangerous, confusing etc., at least in current
>circumstances.

See above. All arguments are known, to almost everybody, I hope. 

However, that the design was based on an analysis of a large amount of
projects and existing code is somewhat new to me. It would be very
interesting to know, how such analysis could be done in any scientific
manner. I mean precisely:

1. procedures and functions as separate concepts of a subroutine
2. a need to restrict [function] parameters
3. a need to restrict [function] code
4. ways of restricting the parameters and code

with nice diagrams and tables of correlations... (:-))

And honestly, provided all the innovations Ada design brought to
programming languages construction, what was that "real data", back to
late 70s, early 80s?

>Therefore any strong judgement from our side about their past
>decisions - like "error" - seems inappropriate... we weren't insiders of that
>Ada world of the past, and we aren't historians.  So, even you dislike some
>decisions and their apparent consequences, let them still be "decisions", not
>"errors".

Error is a result of a decision. Though the reverse is not true. Not
every decision results in an error.

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

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> Error is a result of a decision. Though the reverse is not true. Not
> every decision results in an error.

I have to agree with Alexandre here.  A lot of effort went into making 
informed decisions on these topics.  Some were easy, and the unanimous 
concensus reflected that.  Others involved tradeoffs and required lots 
of debate and discussion.  Finally, a few issues were clearly about 
style, and there was no right or wrong involved.

I put the decision on function parameters in the last group, along with 
the decision (for Ada 9X) on changing the underscore rule for Ada 
identifiers.  Everyone understood the issues, and for the in out 
function parameters DEC Ada had a pragma that created "value returning 
procedures" as a workaround, so there was real experience with using an 
Ada version that allowed it.

The concensus was strongly in favor of retaining the Ada 83 rule.  This 
was at the Ada 9X meeting in Salem, MA, and at that meeting we took a 
final unanimous vote that everyone present (technically, every country 
represented) was comfortable with all the decisions reached there.

Personally I voted for in out parameters for functions.  But when that 
vote was over, I went and helped design a random number generator 
interface that passed the generator as an in parameter.  The issue had 
been discussed, everyone knew that the effect on the final standard 
would impact the RNG package, and that the vote for the status quo would 
continue to allow functions with side effects. (The option of "fixing" 
functions so that side effects were not allowed was considered, and 
dismissed quickly.  A different decision was made for functions in 
protected objects, which sometimes requires nesting of protected types.) 
  Everyone--including me--was comfortable with the result.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bt8vap$455n1$1@ID-77047.news.uni-berlin.de...
...
> The point is that the code reader should see that the random generator is
> not a pure function of its argument. This has to be seen immediately from
> the specifications, not from a speculation "how-I-would-implement-that".
> This is why either the parameter has to be an access or an in-out.
Anything
> other is wrong, IMO. Similarly the way the operations on File_Type were
> declared is IMO wrong!

You're probably right, but that isn't the model of Ada.

In parameters and constants just provide a constant view of an object. But
nearly every object has a variable view as well -- you just can't explicitly
name it. Initialization and finalization are always done on a variable view
of the object - even if it is declared as a constant.

That will be more obvious in Ada 200Y, because of the ability to initialize
limited objects. A constant of a limited type might contain a task;
certainly that task will run and modify its local objects without any regard
to whether it is declared in a constant or variable. The task will have a
variable view of its containing object, even if the program as a whole only
has a constant view of the object.

                       Randy.

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ds9ivv07np35qqqflj126pg406t4bmd2qh@4ax.com...
...
> Alas, there is no anonymous access-to-constant parameters.

Ada 200Y probably will have those. See AI-231.

                Randy.

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Dmitry A. Kazakov]

On Mon, 5 Jan 2004 21:01:28 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>In parameters and constants just provide a constant view of an object. But
>nearly every object has a variable view as well -- you just can't explicitly
>name it. Initialization and finalization are always done on a variable view
>of the object - even if it is declared as a constant.

Yes. A constant is just something like:

<Invisible> : X := <initial>;
Visible : constant X renames <Invisible>;

This is consistent and fine, because then Initialize/Finalize are
called on <Invisible>. The only problem is when the variable view
becomes available through a constant one. Using Rosen trick, for
instance. I'd like to close such gaps where possible, but it is too
late of course. At least we could reduce unintentional trickery by
allowing return for procedures.

>That will be more obvious in Ada 200Y, because of the ability to initialize
>limited objects. A constant of a limited type might contain a task;
>certainly that task will run and modify its local objects without any regard
>to whether it is declared in a constant or variable. The task will have a
>variable view of its containing object, even if the program as a whole only
>has a constant view of the object.

It is no problem to me, because it would be a designer's choice
whether the task should have an access to the enclosing object (Rosen
trick again).

I share the point that "constant/in" should be only a view. I.e. for
by-reference types it does not propagate down to all components. That
would be either impossible or inconsistent (considering components of
access types). For by-value objects one could imagine that kind of
implementation (a user-defined, of course), though that is irrelevant
as long as such types have no user-defined
constructor/destructor/assignement.

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

Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

[Dmitry A. Kazakov]

On Mon, 5 Jan 2004 21:04:32 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:ds9ivv07np35qqqflj126pg406t4bmd2qh@4ax.com...
>...
>> Alas, there is no anonymous access-to-constant parameters.
>
>Ada 200Y probably will have those. See AI-231.

Great!

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