* Hiding the value of Constants @ 2009-07-07 8:48 Rick 2009-07-07 8:54 ` xavier grave ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Rick @ 2009-07-07 8:48 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 8:48 Hiding the value of Constants Rick @ 2009-07-07 8:54 ` xavier grave 2009-07-07 8:58 ` AdaMagica 2009-07-07 9:41 ` Georg Bauhaus 2009-07-09 23:04 ` anon 2 siblings, 1 reply; 23+ messages in thread From: xavier grave @ 2009-07-07 8:54 UTC (permalink / raw) To: Rick -----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----- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 8:54 ` xavier grave @ 2009-07-07 8:58 ` AdaMagica 0 siblings, 0 replies; 23+ messages in thread From: AdaMagica @ 2009-07-07 8:58 UTC (permalink / raw) My_Funny_Constant_Value: constant My_Funny_Type; -- this is called a deferred constant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 8:48 Hiding the value of Constants Rick 2009-07-07 8:54 ` xavier grave @ 2009-07-07 9:41 ` Georg Bauhaus 2009-07-07 10:41 ` Hibou57 (Yannick Duchêne) 2009-07-09 23:04 ` anon 2 siblings, 1 reply; 23+ messages in thread From: Georg Bauhaus @ 2009-07-07 9:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 9:41 ` Georg Bauhaus @ 2009-07-07 10:41 ` Hibou57 (Yannick Duchêne) 2009-07-07 15:51 ` Adam Beneschan 0 siblings, 1 reply; 23+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2009-07-07 10:41 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 10:41 ` Hibou57 (Yannick Duchêne) @ 2009-07-07 15:51 ` Adam Beneschan 2009-07-07 16:26 ` Hibou57 (Yannick Duchêne) 2009-07-07 18:48 ` Dmitry A. Kazakov 0 siblings, 2 replies; 23+ messages in thread From: Adam Beneschan @ 2009-07-07 15:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 15:51 ` Adam Beneschan @ 2009-07-07 16:26 ` Hibou57 (Yannick Duchêne) 2009-07-07 18:48 ` Dmitry A. Kazakov 1 sibling, 0 replies; 23+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2009-07-07 16:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 15:51 ` Adam Beneschan 2009-07-07 16:26 ` Hibou57 (Yannick Duchêne) @ 2009-07-07 18:48 ` Dmitry A. Kazakov 2009-07-07 19:05 ` Adam Beneschan 1 sibling, 1 reply; 23+ messages in thread From: Dmitry A. Kazakov @ 2009-07-07 18:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 18:48 ` Dmitry A. Kazakov @ 2009-07-07 19:05 ` Adam Beneschan 2009-07-07 19:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 23+ messages in thread From: Adam Beneschan @ 2009-07-07 19:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 19:05 ` Adam Beneschan @ 2009-07-07 19:53 ` Dmitry A. Kazakov 2009-07-07 20:28 ` Adam Beneschan 0 siblings, 1 reply; 23+ messages in thread From: Dmitry A. Kazakov @ 2009-07-07 19:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 19:53 ` Dmitry A. Kazakov @ 2009-07-07 20:28 ` Adam Beneschan 2009-07-07 20:57 ` Dmitry A. Kazakov 0 siblings, 1 reply; 23+ messages in thread From: Adam Beneschan @ 2009-07-07 20:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 20:28 ` Adam Beneschan @ 2009-07-07 20:57 ` Dmitry A. Kazakov 2009-07-08 10:25 ` Georg Bauhaus 0 siblings, 1 reply; 23+ messages in thread From: Dmitry A. Kazakov @ 2009-07-07 20:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 20:57 ` Dmitry A. Kazakov @ 2009-07-08 10:25 ` Georg Bauhaus 2009-07-08 12:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 23+ messages in thread From: Georg Bauhaus @ 2009-07-08 10:25 UTC (permalink / raw) 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 ... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-08 10:25 ` Georg Bauhaus @ 2009-07-08 12:20 ` Dmitry A. Kazakov 0 siblings, 0 replies; 23+ messages in thread From: Dmitry A. Kazakov @ 2009-07-08 12:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-07 8:48 Hiding the value of Constants Rick 2009-07-07 8:54 ` xavier grave 2009-07-07 9:41 ` Georg Bauhaus @ 2009-07-09 23:04 ` anon 2009-07-10 6:37 ` AdaMagica 2 siblings, 1 reply; 23+ messages in thread From: anon @ 2009-07-09 23:04 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-09 23:04 ` anon @ 2009-07-10 6:37 ` AdaMagica 2009-07-11 19:06 ` anon 0 siblings, 1 reply; 23+ messages in thread From: AdaMagica @ 2009-07-10 6:37 UTC (permalink / raw) 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 ; ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-10 6:37 ` AdaMagica @ 2009-07-11 19:06 ` anon 2009-07-11 19:26 ` Georg Bauhaus 0 siblings, 1 reply; 23+ messages in thread From: anon @ 2009-07-11 19:06 UTC (permalink / raw) 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 ; ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 19:06 ` anon @ 2009-07-11 19:26 ` Georg Bauhaus 2009-07-11 21:53 ` anon 0 siblings, 1 reply; 23+ messages in thread From: Georg Bauhaus @ 2009-07-11 19:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 19:26 ` Georg Bauhaus @ 2009-07-11 21:53 ` anon 2009-07-11 22:03 ` Albrecht Käfer ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: anon @ 2009-07-11 21:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 21:53 ` anon @ 2009-07-11 22:03 ` Albrecht Käfer 2009-07-11 22:15 ` Ed Falis 2009-07-11 23:31 ` Egil 2 siblings, 0 replies; 23+ messages in thread From: Albrecht Käfer @ 2009-07-11 22:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 21:53 ` anon 2009-07-11 22:03 ` Albrecht Käfer @ 2009-07-11 22:15 ` Ed Falis 2009-07-15 9:30 ` anon 2009-07-11 23:31 ` Egil 2 siblings, 1 reply; 23+ messages in thread From: Ed Falis @ 2009-07-11 22:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 22:15 ` Ed Falis @ 2009-07-15 9:30 ` anon 0 siblings, 0 replies; 23+ messages in thread From: anon @ 2009-07-15 9:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Hiding the value of Constants 2009-07-11 21:53 ` anon 2009-07-11 22:03 ` Albrecht Käfer 2009-07-11 22:15 ` Ed Falis @ 2009-07-11 23:31 ` Egil 2 siblings, 0 replies; 23+ messages in thread From: Egil @ 2009-07-11 23:31 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-07-15 9:30 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-07 8:48 Hiding the value of Constants Rick 2009-07-07 8:54 ` xavier grave 2009-07-07 8:58 ` AdaMagica 2009-07-07 9:41 ` Georg Bauhaus 2009-07-07 10:41 ` Hibou57 (Yannick Duchêne) 2009-07-07 15:51 ` Adam Beneschan 2009-07-07 16:26 ` Hibou57 (Yannick Duchêne) 2009-07-07 18:48 ` Dmitry A. Kazakov 2009-07-07 19:05 ` Adam Beneschan 2009-07-07 19:53 ` Dmitry A. Kazakov 2009-07-07 20:28 ` Adam Beneschan 2009-07-07 20:57 ` Dmitry A. Kazakov 2009-07-08 10:25 ` Georg Bauhaus 2009-07-08 12:20 ` Dmitry A. Kazakov 2009-07-09 23:04 ` anon 2009-07-10 6:37 ` AdaMagica 2009-07-11 19:06 ` anon 2009-07-11 19:26 ` Georg Bauhaus 2009-07-11 21:53 ` anon 2009-07-11 22:03 ` Albrecht Käfer 2009-07-11 22:15 ` Ed Falis 2009-07-15 9:30 ` anon 2009-07-11 23:31 ` Egil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox