Hiding the value of Constants

Hiding the value of Constants

[Rick]

Is it possible to declare a constant in a package specification
without the user knowing the value of that constant?

--------------------------------------------
Rick Duley
North Perth,
Western Australia
http://rickduley.webs.com
                                      .-_|\
                                     /     \
                               perth *_.-._/
                                          v
aussie : 0409 106 049
o'seas : +61 409 106 049
--------------------------------------------
"Ah, but a man's reach
      should exceed his grasp,
              Or what's a heaven for?"
                Robert Browning (1812-1889)

Re: Hiding the value of Constants

[xavier grave]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rick a �crit :
> Is it possible to declare a constant in a package specification
> without the user knowing the value of that constant?
> 

package Test_Constant is
   pragma Pure;
   type My_Funny_Type is private;
   My_Funny_Constant_Value : constant My_Funny_Type;
private
   type My_Funny_Type is new Integer;
   My_Funny_Constant_Value : constant My_Funny_Type := 0;
end Test_Constant;

Hope it will help
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpTDUoACgkQVIZi0A5BZF5TjACgpVzt1nmCmy2fmuy8S4dsj+bh
IsIAn1XNr94ohlvWt97vuKMNHO5x/aSf
=9Mp6
-----END PGP SIGNATURE-----

Re: Hiding the value of Constants

[AdaMagica]

  My_Funny_Constant_Value: constant My_Funny_Type;  -- this is called
a deferred constant

Re: Hiding the value of Constants

[Georg Bauhaus]

Rick schrieb:
> Is it possible to declare a constant in a package specification
> without the user knowing the value of that constant?

I'm assuming you do not want the value to be
visible neither in the private part nor in the
public part of the package specification?

Use a function then, and make the package pure,
if possible:

package P is

  pragma pure;

  type Thing is ...;

  function My_Constant return Thing;

  pragma Inline(My_constant);

end P;

Chances are that the compiler might be able to
act as if My_Constant was a simple constant.

Re: Hiding the value of Constants

[Hibou57 (Yannick Duchêne)]

On 7 juil, 11:41, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> I'm assuming you do not want the value to be
> visible neither in the private part nor in the
> public part of the package specification?
>
> Use a function then, and make the package pure,
> if possible:
>
> package P is
>
>   pragma pure;
>
>   type Thing is ...;
>
>   function My_Constant return Thing;
>
>   pragma Inline(My_constant);
>
> end P;
>
> Chances are that the compiler might be able to
> act as if My_Constant was a simple constant.

As some one are talking about Funny_Types, here is a funny thing
(thinking about it when I saw this solution) : Ada defines enumeration
contants as parameterless functions (just like you propose for these
constants).

RM 2005 3.5.1 says:
> 6 {enumeration literal} Each enumeration_literal_specification is the
> explicit declaration of the corresponding enumeration literal: it
> declares a parameterless function, whose defining name is the
> defining_identifier or defining_character_literal, and whose result
> type is the enumeration type.

But this is with some restrictions (ex. one may not get the adress of
such a function)

This has some conscequences on the name resolution of an enumeration
literal reference vs of a constant reference. Sometimes I wish both
will be one day handled the same (enumeration literals and constants)

Re: Hiding the value of Constants

[Adam Beneschan]

On Jul 7, 3:41 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:

> As some one are talking about Funny_Types, here is a funny thing
> (thinking about it when I saw this solution) : Ada defines enumeration
> contants as parameterless functions (just like you propose for these
> constants).
>
> RM 2005 3.5.1 says:
>
> > 6 {enumeration literal} Each enumeration_literal_specification is the
> > explicit declaration of the corresponding enumeration literal: it
> > declares a parameterless function, whose defining name is the
> > defining_identifier or defining_character_literal, and whose result
> > type is the enumeration type.
>
> But this is with some restrictions (ex. one may not get the adress of
> such a function)
>
> This has some conscequences on the name resolution of an enumeration
> literal reference vs of a constant reference. Sometimes I wish both
> will be one day handled the same (enumeration literals and constants

I believe the reason enumeration literals are actually functions is so
that you can use the same enumeration literal in more than one
enumeration type and not have to worry about name conflicts.  The
overloading rules will allow the compiler to figure out which one is
meant.  There are additional bonuses, such as being able to use an
enumeration literal as the actual for a generic instantiation that
expects a function.  How useful that is in practice, I don't know.

I'm not sure why you would want enumeration literals to be treated
like constants, though.  I don't know of any advantage to making them
officially "constants"; that is, I can't think of any language rule
off the top of my head where a constant would be allowed but a static
function such as an enumeration literal couldn't.  In effect, I
believe you can use them anywhere a constant could be used, and in
some places where constants can't.  If you mean that you'd like
constants to be treated like static functions, so that you can
overload them:

    Max : constant Integer := 15;
    Max : constant Float := 15.0;

that's an intriguing idea.  Not intriguing enough for me to have to
make all the necessary changes to our compiler, but intriguing
nonetheless....

                                -- Adam

Re: Hiding the value of Constants

[Hibou57 (Yannick Duchêne)]

On 7 juil, 17:51, Adam Beneschan <a...@irvine.com> wrote:
> I believe the reason enumeration literals are actually functions is so
> that you can use the same enumeration literal in more than one
> enumeration type and not have to worry about name conflicts.
I believe the same

> There are additional bonuses, such as being able to use an
> enumeration literal as the actual for a generic instantiation that
> expects a function.  How useful that is in practice, I don't know.
I do not see right away neither, but I don't minde, as it is clear
cristal and as there is nothing of a kind of hack in there.

> I'm not sure why you would want enumeration literals to be treated
> like constants, though.
My words were probably clumsy, beceause I was to suggest the
opposite : treat constants like enumeration literals are.

This would not break any actual code, as actual restrictions on
constants are narrower than the restrictions on enumeration literals.

> If you mean that you'd like
> constants to be treated like static functions, so that you can
> overload them:
>
>     Max : constant Integer := 15;
>     Max : constant Float := 15.0;

That was this one idea, yes :)

> that's an intriguing idea.  Not intriguing enough for me to have to
> make all the necessary changes to our compiler, but intriguing
> nonetheless....
Oops... I apologize, as I'm not a compiler writer (just played with a
tiny-little language of my own, some years ago), I cannot figure out
the amount of difficulty this would involve.

Re: Hiding the value of Constants

[Dmitry A. Kazakov]

On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:

> I believe the reason enumeration literals are actually functions is so
> that you can use the same enumeration literal in more than one
> enumeration type and not have to worry about name conflicts.

It is a strange explanation to me. There is no obvious reason why rules
about overloading named objects should be different for functions. The
effect is same, so the syntactic form should be same.

> The
> overloading rules will allow the compiler to figure out which one is
> meant.  There are additional bonuses, such as being able to use an
> enumeration literal as the actual for a generic instantiation that
> expects a function.  How useful that is in practice, I don't know.

It is indeed useful, because sometimes it is impossible to declare a ting
as an initialized constant. In such cases making it a function gives the
desired effect.

[...]
> If you mean that you'd like
> constants to be treated like static functions, so that you can
> overload them:
> 
>     Max : constant Integer := 15;
>     Max : constant Float := 15.0;
> 
> that's an intriguing idea.

I think the idea is rather straightforward. But also

   X : Integer;
   X : Float;

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

Re: Hiding the value of Constants

[Adam Beneschan]

On Jul 7, 11:48 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
> > I believe the reason enumeration literals are actually functions is so
> > that you can use the same enumeration literal in more than one
> > enumeration type and not have to worry about name conflicts.
>
> It is a strange explanation to me. There is no obvious reason why rules
> about overloading named objects should be different for functions. The
> effect is same, so the syntactic form should be same.
>
> > The
> > overloading rules will allow the compiler to figure out which one is
> > meant.  There are additional bonuses, such as being able to use an
> > enumeration literal as the actual for a generic instantiation that
> > expects a function.  How useful that is in practice, I don't know.
>
> It is indeed useful, because sometimes it is impossible to declare a ting
> as an initialized constant. In such cases making it a function gives the
> desired effect.
>
> [...]
>
> > If you mean that you'd like
> > constants to be treated like static functions, so that you can
> > overload them:
>
> >     Max : constant Integer := 15;
> >     Max : constant Float := 15.0;
>
> > that's an intriguing idea.
>
> I think the idea is rather straightforward. But also
>
>    X : Integer;
>    X : Float;

I'm just guessing here, but I think a big potential problem would be
if objects of the same name were declared in different scopes.  If a
nested subroutine has a local variable

    X : Integer;

and the body says

    X := False;

the compiler will complain.  But if the outer subroutine has its own
local variable X of type Boolean, the compiler wouldn't catch this.

I realize that subprogram overloading can sometimes lead to the same
kinds of situations where the compiler doesn't catch an error because
you used the wrong parameter type, for example; and since subprograms
can be declared implicitly, when a type is derived e.g., it might be
hard to track down problems like that.  I suppose that the question
is, what's the risk/benefit ratio in each case.  It could be that the
benefits of having overloaded subprograms available outweighs the
problems (confusion and failure to catch some errors at compile time)
of making subprograms in an outer scope visible, while in the case of
variables the problems outweigh the potential benefits (especially if
nobody would really *want* to declare two variables with the same name
and have them both visible).  Yes, that makes things inconsistent,
which I know isn't going to please people who like to look at the
world through theoretical eyes.  Oh, well.

                                             -- Adam

Re: Hiding the value of Constants

[Dmitry A. Kazakov]

On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:

> On Jul 7, 11:48�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
>>> I believe the reason enumeration literals are actually functions is so
>>> that you can use the same enumeration literal in more than one
>>> enumeration type and not have to worry about name conflicts.
>>
>> It is a strange explanation to me. There is no obvious reason why rules
>> about overloading named objects should be different for functions. The
>> effect is same, so the syntactic form should be same.
>>
>>> The
>>> overloading rules will allow the compiler to figure out which one is
>>> meant. �There are additional bonuses, such as being able to use an
>>> enumeration literal as the actual for a generic instantiation that
>>> expects a function. �How useful that is in practice, I don't know.
>>
>> It is indeed useful, because sometimes it is impossible to declare a ting
>> as an initialized constant. In such cases making it a function gives the
>> desired effect.
>>
>> [...]
>>
>>> If you mean that you'd like
>>> constants to be treated like static functions, so that you can
>>> overload them:
>>
>>> � � Max : constant Integer := 15;
>>> � � Max : constant Float := 15.0;
>>
>>> that's an intriguing idea.
>>
>> I think the idea is rather straightforward. But also
>>
>> � �X : Integer;
>> � �X : Float;
> 
> I'm just guessing here, but I think a big potential problem would be
> if objects of the same name were declared in different scopes.  If a
> nested subroutine has a local variable
> 
>     X : Integer;
> 
> and the body says
> 
>     X := False;
> 
> the compiler will complain.  But if the outer subroutine has its own
> local variable X of type Boolean, the compiler wouldn't catch this.
> 
> I realize that subprogram overloading can sometimes lead to the same
> kinds of situations where the compiler doesn't catch an error because
> you used the wrong parameter type, for example; and since subprograms
> can be declared implicitly, when a type is derived e.g., it might be
> hard to track down problems like that.  I suppose that the question
> is, what's the risk/benefit ratio in each case.  It could be that the
> benefits of having overloaded subprograms available outweighs the
> problems (confusion and failure to catch some errors at compile time)
> of making subprograms in an outer scope visible, while in the case of
> variables the problems outweigh the potential benefits (especially if
> nobody would really *want* to declare two variables with the same name
> and have them both visible).  Yes, that makes things inconsistent,
> which I know isn't going to please people who like to look at the
> world through theoretical eyes.  Oh, well.

Yes, but. I remember how it was programmed in FORTRAN - very few
subprograms, a lot of variables declared in. The programming style has
dramatically changed since then. Ada 2005 is a very different language. How
many variables are visible in a scope of a normal Ada program? 3-5, maybe
10 counting formal parameters. How many subprograms? Hundreds? Thousands?

Is the issue of hiding variables really actual?

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

Re: Hiding the value of Constants

[Adam Beneschan]

On Jul 7, 12:53 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:
> > On Jul 7, 11:48 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
> >>> I believe the reason enumeration literals are actually functions is so
> >>> that you can use the same enumeration literal in more than one
> >>> enumeration type and not have to worry about name conflicts.
>
> >> It is a strange explanation to me. There is no obvious reason why rules
> >> about overloading named objects should be different for functions. The
> >> effect is same, so the syntactic form should be same.
>
> >>> The
> >>> overloading rules will allow the compiler to figure out which one is
> >>> meant.  There are additional bonuses, such as being able to use an
> >>> enumeration literal as the actual for a generic instantiation that
> >>> expects a function.  How useful that is in practice, I don't know.
>
> >> It is indeed useful, because sometimes it is impossible to declare a ting
> >> as an initialized constant. In such cases making it a function gives the
> >> desired effect.
>
> >> [...]
>
> >>> If you mean that you'd like
> >>> constants to be treated like static functions, so that you can
> >>> overload them:
>
> >>>     Max : constant Integer := 15;
> >>>     Max : constant Float := 15.0;
>
> >>> that's an intriguing idea.
>
> >> I think the idea is rather straightforward. But also
>
> >>    X : Integer;
> >>    X : Float;
>
> > I'm just guessing here, but I think a big potential problem would be
> > if objects of the same name were declared in different scopes.  If a
> > nested subroutine has a local variable
>
> >     X : Integer;
>
> > and the body says
>
> >     X := False;
>
> > the compiler will complain.  But if the outer subroutine has its own
> > local variable X of type Boolean, the compiler wouldn't catch this.
>
> > I realize that subprogram overloading can sometimes lead to the same
> > kinds of situations where the compiler doesn't catch an error because
> > you used the wrong parameter type, for example; and since subprograms
> > can be declared implicitly, when a type is derived e.g., it might be
> > hard to track down problems like that.  I suppose that the question
> > is, what's the risk/benefit ratio in each case.  It could be that the
> > benefits of having overloaded subprograms available outweighs the
> > problems (confusion and failure to catch some errors at compile time)
> > of making subprograms in an outer scope visible, while in the case of
> > variables the problems outweigh the potential benefits (especially if
> > nobody would really *want* to declare two variables with the same name
> > and have them both visible).  Yes, that makes things inconsistent,
> > which I know isn't going to please people who like to look at the
> > world through theoretical eyes.  Oh, well.
>
> Yes, but. I remember how it was programmed in FORTRAN - very few
> subprograms, a lot of variables declared in. The programming style has
> dramatically changed since then. Ada 2005 is a very different language. How
> many variables are visible in a scope of a normal Ada program? 3-5, maybe
> 10 counting formal parameters. How many subprograms? Hundreds? Thousands?
>
> Is the issue of hiding variables really actual?

The rules about overloading and visibility go back to Ada 83.  In Ada
83, there were more restrictions on the order of things in a
declarative part.  If procedure Proc1 had a nested procedure Proc2,
Proc2's body could not appear before any of Proc1's local variables.
Thus, whatever work or temporary variables, etc., that Proc1 needed,
would necessarily be visible to Proc2.  (You could work around this by
making Proc2's body a *block* and declaring the locals there.  But
doubtless not everybody did that.)  Under those rules, then yes, a lot
of variables could be visible to a nested subprogram.  The same issues
apply to subprograms in a package body; the Ada 83 rules stated that
the subprogram bodies had to appear after any variable declarations in
the package body.

The order restrictions are gone in Ada 95 and Ada 2005, but there's
still plenty of Ada 83 code out there that the language designers have
to concern themselves with.  Programmers still have to maintain Ada 83
code, and we don't want to tell them that they have to rearrange all
their code in order to avoid possible errors.

Anyway, although we could have a discussion about this point, I doubt
that anything will change.  It would require a lot of work for
compiler maintainers (like me) to implement this change, and it's for
a feature that as far as I know nobody really is itching for.  And I
don't think a language change that dumps a lot of work on compiler
maintainers with almost no practical benefit to any users is likely to
happen, even if it would make the language more consistent and thus
more pleasing to theoreticians.

                                   -- Adam

Re: Hiding the value of Constants

[Dmitry A. Kazakov]

On Tue, 7 Jul 2009 13:28:01 -0700 (PDT), Adam Beneschan wrote:

> On Jul 7, 12:53�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:
>>> On Jul 7, 11:48�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
>>>>> I believe the reason enumeration literals are actually functions is so
>>>>> that you can use the same enumeration literal in more than one
>>>>> enumeration type and not have to worry about name conflicts.
>>
>>>> It is a strange explanation to me. There is no obvious reason why rules
>>>> about overloading named objects should be different for functions. The
>>>> effect is same, so the syntactic form should be same.
>>
>>>>> The
>>>>> overloading rules will allow the compiler to figure out which one is
>>>>> meant. �There are additional bonuses, such as being able to use an
>>>>> enumeration literal as the actual for a generic instantiation that
>>>>> expects a function. �How useful that is in practice, I don't know.
>>
>>>> It is indeed useful, because sometimes it is impossible to declare a ting
>>>> as an initialized constant. In such cases making it a function gives the
>>>> desired effect.
>>
>>>> [...]
>>
>>>>> If you mean that you'd like
>>>>> constants to be treated like static functions, so that you can
>>>>> overload them:
>>
>>>>> � � Max : constant Integer := 15;
>>>>> � � Max : constant Float := 15.0;
>>
>>>>> that's an intriguing idea.
>>
>>>> I think the idea is rather straightforward. But also
>>
>>>> � �X : Integer;
>>>> � �X : Float;
>>
>>> I'm just guessing here, but I think a big potential problem would be
>>> if objects of the same name were declared in different scopes. �If a
>>> nested subroutine has a local variable
>>
>>> � � X : Integer;
>>
>>> and the body says
>>
>>> � � X := False;
>>
>>> the compiler will complain. �But if the outer subroutine has its own
>>> local variable X of type Boolean, the compiler wouldn't catch this.
>>
>>> I realize that subprogram overloading can sometimes lead to the same
>>> kinds of situations where the compiler doesn't catch an error because
>>> you used the wrong parameter type, for example; and since subprograms
>>> can be declared implicitly, when a type is derived e.g., it might be
>>> hard to track down problems like that. �I suppose that the question
>>> is, what's the risk/benefit ratio in each case. �It could be that the
>>> benefits of having overloaded subprograms available outweighs the
>>> problems (confusion and failure to catch some errors at compile time)
>>> of making subprograms in an outer scope visible, while in the case of
>>> variables the problems outweigh the potential benefits (especially if
>>> nobody would really *want* to declare two variables with the same name
>>> and have them both visible). �Yes, that makes things inconsistent,
>>> which I know isn't going to please people who like to look at the
>>> world through theoretical eyes. �Oh, well.
>>
>> Yes, but. I remember how it was programmed in FORTRAN - very few
>> subprograms, a lot of variables declared in. The programming style has
>> dramatically changed since then. Ada 2005 is a very different language. How
>> many variables are visible in a scope of a normal Ada program? 3-5, maybe
>> 10 counting formal parameters. How many subprograms? Hundreds? Thousands?
>>
>> Is the issue of hiding variables really actual?
> 
> The rules about overloading and visibility go back to Ada 83.

Yes, that is my point. FORTRAN-style programs were actual then.

> In Ada
> 83, there were more restrictions on the order of things in a
> declarative part.  If procedure Proc1 had a nested procedure Proc2,
> Proc2's body could not appear before any of Proc1's local variables.

Wow, I don't remember that (if I ever knew (:-))

> Anyway, although we could have a discussion about this point, I doubt
> that anything will change.  It would require a lot of work for
> compiler maintainers (like me) to implement this change, and it's for
> a feature that as far as I know nobody really is itching for.  And I
> don't think a language change that dumps a lot of work on compiler
> maintainers with almost no practical benefit to any users is likely to
> happen, even if it would make the language more consistent and thus
> more pleasing to theoreticians.

I agree that it is a feature nobody would care to push for. But still the
rules need to be rethought in the light of new reality. Because on the
other side, I believe, nobody is satisfied how the rules handle subprograms
and primitive operations. It is too easy to design a package specification
which would make it unusable because of ambiguities introduced by
"use"-ing. Yes prefix notation makes life easier, but it does not
exterminate need in "use". Something quite radical has to be done about it
anyway. One spends virtually hours trying to find a reason why the compiler
rejects an interpretation the programmer sees as "obvious". It gets worse
and worse, despite all support a good compiler like GNAT could give.

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

Re: Hiding the value of Constants

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Tue, 7 Jul 2009 13:28:01 -0700 (PDT), Adam Beneschan wrote:
> 
>> On Jul 7, 12:53 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:
>>>> On Jul 7, 11:48 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>>> wrote:
>>>>> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
>>>>>> I believe the reason enumeration literals are actually functions is so
>>>>>> that you can use the same enumeration literal in more than one
>>>>>> enumeration type and not have to worry about name conflicts.
>>>>> It is a strange explanation to me. There is no obvious reason why rules
>>>>> about overloading named objects should be different for functions. The
>>>>> effect is same, so the syntactic form should be same.
>>>>>> The
>>>>>> overloading rules will allow the compiler to figure out which one is
>>>>>> meant.  There are additional bonuses, such as being able to use an
>>>>>> enumeration literal as the actual for a generic instantiation that
>>>>>> expects a function.  How useful that is in practice, I don't know.
>>>>> It is indeed useful, because sometimes it is impossible to declare a ting
>>>>> as an initialized constant. In such cases making it a function gives the
>>>>> desired effect.
>>>>> [...]
>>>>>> If you mean that you'd like
>>>>>> constants to be treated like static functions, so that you can
>>>>>> overload them:
>>>>>>     Max : constant Integer := 15;
>>>>>>     Max : constant Float := 15.0;
>>>>>> that's an intriguing idea.
>>>>> I think the idea is rather straightforward. But also
>>>>>    X : Integer;
>>>>>    X : Float;
>>>> I'm just guessing here, but I think a big potential problem would be

[...]

> I believe, nobody is satisfied how the rules handle subprograms
> and primitive operations. It is too easy to design a package specification
> which would make it unusable because of ambiguities introduced by
> "use"-ing. Yes prefix notation makes life easier, but it does not
> exterminate need in "use". Something quite radical has to be done about it
> anyway. One spends virtually hours trying to find a reason why the compiler
> rejects an interpretation the programmer sees as "obvious".

The programmer seeing something as "obvious" is a hint to
what the problem with overloading actually is, and what the
(radical) solution looks like.  (Really radical, in a gardening
sense, sort of. :-)   Here, again, is the Max example:

   Max : constant Integer := 15;
   Max : constant Float := 15.0;

What seems obvious to me is that the programmer intends to
express the Max of two somethings that share some common
property: they both have a Max.  But he/she wishes to do so
*without* explicitly programming the underlying common
structure!  Perhaps it seemed obvious when writing the code,
or being lazy and not explicitly programming the common
property seemed justifiable at the time of writing.
IMHO this is an example of the presumption of "being obvious"
making things unecessarily complicated: the compiler would
have to resolve the overload that was introduced by the
programmer who *knew* how to resolve both the commonality
and the difference. (There are means in Ada to express
the same algorithm for two data structures, but anyway ...)

The radical solution is to finally get rid of overloading!
Just use one name for one thing in one region.  See SPARK
for an example.

In Ada, not using generics, but using overridden Max,

   Bounded_Structure: Finite_Order'class := ...;
begin
   if Item < Bounded_Structure.Max then
      ...

Re: Hiding the value of Constants

[Dmitry A. Kazakov]

On Wed, 08 Jul 2009 12:25:23 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Tue, 7 Jul 2009 13:28:01 -0700 (PDT), Adam Beneschan wrote:
>> 
>>> On Jul 7, 12:53 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:

>> I believe, nobody is satisfied how the rules handle subprograms
>> and primitive operations. It is too easy to design a package specification
>> which would make it unusable because of ambiguities introduced by
>> "use"-ing. Yes prefix notation makes life easier, but it does not
>> exterminate need in "use". Something quite radical has to be done about it
>> anyway. One spends virtually hours trying to find a reason why the compiler
>> rejects an interpretation the programmer sees as "obvious".
> 
> The programmer seeing something as "obvious" is a hint to
> what the problem with overloading actually is, and what the
> (radical) solution looks like.  (Really radical, in a gardening
> sense, sort of. :-)   Here, again, is the Max example:
> 
>    Max : constant Integer := 15;
>    Max : constant Float := 15.0;
> 
> What seems obvious to me is that the programmer intends to
> express the Max of two somethings that share some common
> property: they both have a Max.  But he/she wishes to do so
> *without* explicitly programming the underlying common
> structure!

I don't see how an underlying structure would help. Consider both Integer
and Float descendants of some Numeric type. Does that change anything? (see
also below)

>  Perhaps it seemed obvious when writing the code,
> or being lazy and not explicitly programming the common
> property seemed justifiable at the time of writing.
> IMHO this is an example of the presumption of "being obvious"
> making things unecessarily complicated: the compiler would
> have to resolve the overload that was introduced by the
> programmer who *knew* how to resolve both the commonality
> and the difference. (There are means in Ada to express
> the same algorithm for two data structures, but anyway ...)

I think that the idea is to express a commonality rather than resolve it.
As an example take Integer'Last and Float'Last. Why they are allowed to be
visible in the same context? How (semantically) they differ from Max?

> The radical solution is to finally get rid of overloading!

Yes, it is a very attractive idea. But the problem is, how to live with "+"
defined both on Integer and Float? As I said earlier, the problem is not
with variables. I think the language will continue reducing the number of
declared variables down to virtually none. The problem is thousands of
operations and types. Where would you get different names for all of them?
How are you going to remember that mess? Consider a typical design of a
library based on generics. It forces you to have identical names for
everything declared in a generic package. The difference happens in the
instances of. The names of the instances is a traditional torture to
invent. As a result they are absolutely meaningless and impossible to
remember. The compiler too has no idea how to help you in finding an
instance of "indexing" a "generic map" with the element "T".

> Just use one name for one thing in one region.  See SPARK
> for an example.
> 
> In Ada, not using generics, but using overridden Max,
> 
>    Bounded_Structure: Finite_Order'class := ...;
> begin
>    if Item < Bounded_Structure.Max then
>       ...

You forgot that a polymorphic operation (Max) is a set of overloaded
specific bodies. You have to allow specific bodies being named. In Ada
these names overload. So the only way not to do it, is to go the path of
C++ by providing unique names mangled by the type signatures, e.g.
Max<Integer>. Interestingly, this is how Ada 83 started. It still has
disgusting attributes taking the form Type'Name. I hope you would agree
that this is a road to hell?

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

Re: Hiding the value of Constants

[anon]

This program and package shows how to hide an Integer. I guess the other 
guys are too busy.

--
-- Test program
--
with Ada.Text_IO ;
use  Ada.Text_IO ;

with Y1 ;
use  Y1 ;

procedure Y is

begin
  Put ( "Hidden String" ) ;
  Put ( Integer'Image ( Test_Value ) ) ;
  New_Line ;
end Y ;

--
-- specs 
--

package Y1 is

  Test_Value : Integer ; -- Value is hidden

  procedure dummy ; -- stops the compiler warnings
                    -- normally replaced by usable 
                    -- routines.

end Y1 ;

--
-- Body 
--
package body Y1 is

  procedure dummy is -- stops the compiler warnings
    begin
      null ;
    end dummy ;

begin  -- Elaboration initializes variable

  Test_Value := 50 ;

end Y1 ;




In <30696d63-16e8-44e2-a4a5-db5095d7cfec@m3g2000pri.googlegroups.com>, Rick <rickduley@gmail.com> writes:
>Is it possible to declare a constant in a package specification
>without the user knowing the value of that constant?
>
>--------------------------------------------
>Rick Duley
>North Perth,
>Western Australia
>http://rickduley.webs.com
>                                      .-_|\
>                                     /     \
>                               perth *_.-._/
>                                          v
>aussie : 0409 106 049
>o'seas : +61 409 106 049
>--------------------------------------------
>"Ah, but a man's reach
>      should exceed his grasp,
>              Or what's a heaven for?"
>                Robert Browning (1812-1889)

Re: Hiding the value of Constants

[AdaMagica]

On 10 Jul., 01:04, a...@anon.org (anon) wrote:
> This program and package shows how to hide an Integer. I guess the other
> guys are too busy.

Rick wanted to know how to hide a constant's value, so this is not
what he asked for. This has been answered long ago.

> package Y1 is
>
>   Test_Value : Integer ; -- Value is hidden
>
>   procedure dummy ; -- stops the compiler warnings
>                     -- normally replaced by usable
>                     -- routines.
>
> end Y1 ;

You mean the warning that this package does not allow a body without
this Dummy?
If you need a body, do not define junk subprograms, use pragma
Elaborate_Body instead.

package Y1 is
  pragma Elaborate_Body;
  Test_Value: Integer; -- Only initial value is hidden (if there
really is one),
                       -- it can be written by anyone.
end Y1 ;

Re: Hiding the value of Constants

[anon]

Like I sometime say, this preson could be a student so, you show 
him part of the answer but not al .  It works, and it will work if you 
change the statement by using "constant" too.  But you may have to 
add a couple of other statements, or not.

In <a6924870-4fe8-4e56-8a5b-23a663262778@d32g2000yqh.googlegroups.com>, AdaMagica <christoph.grein@eurocopter.com> writes:
>On 10 Jul., 01:04, a...@anon.org (anon) wrote:
>> This program and package shows how to hide an Integer. I guess the other
>> guys are too busy.
>
>Rick wanted to know how to hide a constant's value, so this is not
>what he asked for. This has been answered long ago.
>
>> package Y1 is
>>
>> =A0 Test_Value : Integer ; -- Value is hidden
>>
>> =A0 procedure dummy ; -- stops the compiler warnings
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- normally replaced by usable
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- routines.
>>
>> end Y1 ;
>
>You mean the warning that this package does not allow a body without
>this Dummy?
>If you need a body, do not define junk subprograms, use pragma
>Elaborate_Body instead.
>
>package Y1 is
>  pragma Elaborate_Body;
>  Test_Value: Integer; -- Only initial value is hidden (if there
>really is one),
>                       -- it can be written by anyone.
>end Y1 ;

Re: Hiding the value of Constants

[Georg Bauhaus]

anon wrote:
> Like I sometime say, this preson could be a student so, you show 
> him part of the answer but not al .

Yes. But in this case it seems fair to conclude,
after reading the OP's messages, that there is no basis
for an assumption like this. So this sounds kind of inadequate,
at best, pardon me.

> It works, and it will work if you 
> change the statement by using "constant" too.

No, it doesn't ...

>  But you may have to 
> add a couple of other statements,

... Yes...

> or not.

No...

Teaching by creative progression using intermittent reinforcement
is probably not a good excuse for the teacher missing the point?
In particular when the "pupil" demonstrates prior knowledge beyond
the above assumption ("my trusty Ada 95 Q&S guide...", he said, e.g.).
Please.

Re: Hiding the value of Constants

[anon]

In the years, there has been a few people asking how to hide values or constant. 
Some say use private which the value is still known. Others say use functions 
which can be hidden by removing the source code of the body of the package, 
but requires a call runtime routine each time the value is needed. 

But the main problem is that each person who wants to hide a constant forgets 
is that all someone has to do is to write a simple program to print the value.  
So, except to may be getting bonus points from a prof, its a waste of time.

In my example I just showed a third way. To initialize the value at the 
Elaboration time instead of compile or using main runtime. 

You need to spead your weekends learning a few ticks of the trade about Ada.
The program works. Just play with it, you might learn that using functions or 
private section to hide a value is not the only way.


In <4a58e74a$0$30233$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
>anon wrote:
>> Like I sometime say, this preson could be a student so, you show 
>> him part of the answer but not al .
>
>Yes. But in this case it seems fair to conclude,
>after reading the OP's messages, that there is no basis
>for an assumption like this. So this sounds kind of inadequate,
>at best, pardon me.
>
>> It works, and it will work if you 
>> change the statement by using "constant" too.
>
>No, it doesn't ...
>
>>  But you may have to 
>> add a couple of other statements,
>
>.... Yes...
>
>> or not.
>
>No...
>
>Teaching by creative progression using intermittent reinforcement
>is probably not a good excuse for the teacher missing the point?
>In particular when the "pupil" demonstrates prior knowledge beyond
>the above assumption ("my trusty Ada 95 Q&S guide...", he said, e.g.).
>Please.

Re: Hiding the value of Constants

[Albrecht Käfer]

anon schrieb:
> In the years, there has been a few people asking how to hide values or constant.
> Some say use private which the value is still known. Others say use functions
> which can be hidden by removing the source code of the body of the package,
> but requires a call runtime routine each time the value is needed.

Not necessarily. There's something called "optimizer" for things like these.

> But the main problem is that each person who wants to hide a constant forgets
> is that all someone has to do is to write a simple program to print the value.

Er ... what?

> In my example I just showed a third way. To initialize the value at the
> Elaboration time instead of compile or using main runtime.

But you do know why constants are called constants, right? How exactly
was your example declaring a constant?


Albrecht

Re: Hiding the value of Constants

[Ed Falis]

On Sat, 11 Jul 2009 17:53:15 -0400, anon <anon@anon.org> wrote:

> In the years, there has been a few people asking how to hide values or  
> constant.
> Some say use private which the value is still known. Others say use  
> functions
> which can be hidden by removing the source code of the body of the  
> package,
> but requires a call runtime routine each time the value is needed.
>
> But the main problem is that each person who wants to hide a constant  
> forgets
> is that all someone has to do is to write a simple program to print the  
> value.
> So, except to may be getting bonus points from a prof, its a waste of  
> time.
>
> In my example I just showed a third way. To initialize the value at the
> Elaboration time instead of compile or using main runtime.
>
> You need to spead your weekends learning a few ticks of the trade about  
> Ada.
> The program works. Just play with it, you might learn that using  
> functions or
> private section to hide a value is not the only way.

"Information Hiding" is not about hiding information from programmers.   
It's about removing details that are irrelevant to clients of an interface  
to services, in order to give more flexibility to the implementation of a  
service and to make the client code's view of the service as essential as  
possible.  This reduces the need to rewrite client code when the  
implementation of a service is modified.  Tucker Taft had a way of  
characterizing the difference between the public and private parts of  
package specs that I still find appealing:  the public part presents the  
logical interface to client code; the private part presents the physical  
part of the interface that is needed by the compiler for it to be  
efficient (or to deal with extra-language representation issues).  This  
can be contrasted with more extreme approaches to "information hiding"  
that use opaque types in the overall spec, deferring all detail to the  
package body (and so invoking extra indirections).

- Ed

Re: Hiding the value of Constants

[anon]

As for the client, they normally never looks at any part of the source code. 
They save that job for their IT or programmer that is maintaining the code for 
them.  The exception may be when the code is a library, where the code 
could be use by other programmers, but if the code is open source or under the 
GPL all they need to do is check either the body or specification file aka no 
hidden value. So, anyone that uses the word "Hide" or varying of the word 
"Hide" is taking about closing the source or information from the client or 
other programmers.

And many who ask about hidding values also ask about open/close source or 
the GPL, if you check their post. They want to hide the code from other 
programmer, hopely its a legal reason.  And the original poster did not say 
anything about using the private section.

In <op.uwxb30pz5afhvo@naropa>, "Ed Falis" <falis@verizon.net> writes:
>On Sat, 11 Jul 2009 17:53:15 -0400, anon <anon@anon.org> wrote:
>
>> In the years, there has been a few people asking how to hide values or  
>> constant.
>> Some say use private which the value is still known. Others say use  
>> functions
>> which can be hidden by removing the source code of the body of the  
>> package,
>> but requires a call runtime routine each time the value is needed.
>>
>> But the main problem is that each person who wants to hide a constant  
>> forgets
>> is that all someone has to do is to write a simple program to print the  
>> value.
>> So, except to may be getting bonus points from a prof, its a waste of  
>> time.
>>
>> In my example I just showed a third way. To initialize the value at the
>> Elaboration time instead of compile or using main runtime.
>>
>> You need to spead your weekends learning a few ticks of the trade about  
>> Ada.
>> The program works. Just play with it, you might learn that using  
>> functions or
>> private section to hide a value is not the only way.
>
>"Information Hiding" is not about hiding information from programmers.   
>It's about removing details that are irrelevant to clients of an interface  
>to services, in order to give more flexibility to the implementation of a  
>service and to make the client code's view of the service as essential as  
>possible.  This reduces the need to rewrite client code when the  
>implementation of a service is modified.  Tucker Taft had a way of  
>characterizing the difference between the public and private parts of  
>package specs that I still find appealing:  the public part presents the  
>logical interface to client code; the private part presents the physical  
>part of the interface that is needed by the compiler for it to be  
>efficient (or to deal with extra-language representation issues).  This  
>can be contrasted with more extreme approaches to "information hiding"  
>that use opaque types in the overall spec, deferring all detail to the  
>package body (and so invoking extra indirections).
>
>- Ed

Re: Hiding the value of Constants

[Egil]

On Jul 11, 11:53 pm, a...@anon.org (anon) wrote:
> In the years, there has been a few people asking how to hide values or constant.
> Some say use private which the value is still known. Others say use functions
> which can be hidden by removing the source code of the body of the package,
> but requires a call runtime routine each time the value is needed.
>
> But the main problem is that each person who wants to hide a constant forgets
> is that all someone has to do is to write a simple program to print the value.  
> So, except to may be getting bonus points from a prof, its a waste of time.
>
> In my example I just showed a third way. To initialize the value at the
> Elaboration time instead of compile or using main runtime.
>
>


Then how about showing an example that is not dependent on the
elaboration order?
ie, a program that does not use an unitialized value for your
Test_Value if a user decides to depend on it for another constant
defined in another package (that happens to be elaborated before the
body of your Y1).