* Test for constant (or "in parameter" in procedure) @ 2017-02-09 4:38 reinkor 2017-02-09 12:11 ` AdaMagica 2017-03-26 20:57 ` Norman Worth 0 siblings, 2 replies; 14+ messages in thread From: reinkor @ 2017-02-09 4:38 UTC (permalink / raw) Hi, is it a good way to test if an object is a constant or not (or "in parameter" in a procedure)? Something in addition to declare it as a constant? If I am sure an object is a constant (and can check it) then this can sometimes help to structure/optimize the code. I would like to have some redundancy and make sure an object is really constant when this is a prerequisite for a piece of code to be according to my intentions - i.e. if the object is messed with somewhere, then things could go wrong. So I would like some "local check" to be sure a constant is really a constant :-) Specially if many people are involved to change code over time. reinert ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 4:38 Test for constant (or "in parameter" in procedure) reinkor @ 2017-02-09 12:11 ` AdaMagica 2017-02-09 12:46 ` reinkor 2017-03-26 20:57 ` Norman Worth 1 sibling, 1 reply; 14+ messages in thread From: AdaMagica @ 2017-02-09 12:11 UTC (permalink / raw) What do you mean by testing for constantness? An object is either declared constant or not; it's either an in-parameter or not. But be careful: Especially for immutably limited types, you cannot (and need not) know what's going on behind the screen. (E.g. what would a constant task object mean? And think of the Rosen trick!) It's completely up to the implementor of an immutably limited object to behave correctly under all circumstances. You, the user, cannot know whether it's truely constant or not. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 12:11 ` AdaMagica @ 2017-02-09 12:46 ` reinkor 2017-02-09 13:09 ` Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: reinkor @ 2017-02-09 12:46 UTC (permalink / raw) OK, I here try to communicate my intention via this simple example: i : Constant Integer := 5; -- all OK so far (but someone could change this to a variable) begin .... some code ... if "i is not constant (cannot change value)" then Some_error_handling; end if; (or alternatively error message/warning at compilation) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 12:46 ` reinkor @ 2017-02-09 13:09 ` Dmitry A. Kazakov 2017-02-09 14:10 ` AdaMagica ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Dmitry A. Kazakov @ 2017-02-09 13:09 UTC (permalink / raw) On 09/02/2017 13:46, reinkor wrote: > OK, I here try to communicate my intention via this simple example: > > i : Constant Integer := 5; -- all OK so far (but someone could > change this to a variable) > > begin > > .... some code ... > > if "i is not constant (cannot change value)" then > Some_error_handling; > end if; i cannot change its value all its life time. This is regardless how its initial value was obtained. > (or alternatively error message/warning at compilation) Maybe we could help better if you tell us what the original problem is. If you consider this: loop declare I : constant Integer := Read_From_File; begin ... end; end loop; It would be meaningless to ask if I changes its value. There are many I's all unrelated to each other. If you want to relate them, you must move the declaration of I to the least common scope, e.g. like this: declare I : Integer; -- Now it is only one I for each iteration begin loop I := Read_From_File; ... end loop; end; You can immediately see that I is not a constant. And you could not make it constant. As it was said, it is either constant (immutable) or not (mutable). Your very question is meaningless. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 12:46 ` reinkor 2017-02-09 13:09 ` Dmitry A. Kazakov @ 2017-02-09 14:10 ` AdaMagica 2017-02-09 15:01 ` reinkor 2017-02-09 16:51 ` G.B. 2017-02-09 18:03 ` Jeffrey R. Carter 3 siblings, 1 reply; 14+ messages in thread From: AdaMagica @ 2017-02-09 14:10 UTC (permalink / raw) Am Donnerstag, 9. Februar 2017 13:46:45 UTC+1 schrieb reinkor: > OK, I here try to communicate my intention via this simple example: > > i : Constant Integer := 5; -- all OK so far (but someone could > change this to a variable) You mean, someone later removes the constant keyword? Well, now, against what stupidities do you want to make your code safe? There will always be some who know what they do and others who don't. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 14:10 ` AdaMagica @ 2017-02-09 15:01 ` reinkor 0 siblings, 0 replies; 14+ messages in thread From: reinkor @ 2017-02-09 15:01 UTC (permalink / raw) On Thursday, February 9, 2017 at 3:10:57 PM UTC+1, AdaMagica wrote: > Am Donnerstag, 9. Februar 2017 13:46:45 UTC+1 schrieb reinkor: > > OK, I here try to communicate my intention via this simple example: > > > > i : Constant Integer := 5; -- all OK so far (but someone could > > change this to a variable) > > You mean, someone later removes the constant keyword? > Bingo ! (and assume the code is somehow complex and I is set in another package) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 12:46 ` reinkor 2017-02-09 13:09 ` Dmitry A. Kazakov 2017-02-09 14:10 ` AdaMagica @ 2017-02-09 16:51 ` G.B. 2017-02-09 16:59 ` reinkor 2017-02-09 18:46 ` Niklas Holsti 2017-02-09 18:03 ` Jeffrey R. Carter 3 siblings, 2 replies; 14+ messages in thread From: G.B. @ 2017-02-09 16:51 UTC (permalink / raw) On 09.02.17 13:46, reinkor wrote: > OK, I here try to communicate my intention via this simple example: > > i : Constant Integer := 5; -- all OK so far (but someone could > change this to a variable) > You could try making it more difficult for programmers you seemingly need to fight in source text by - by making i a function; hide its body, - make your code depend on compile time static constants. I'd suggest that it is time, technically, for your boss or for yourself to call for discipline, or ask you lawyer about what your contracts require you to guarantee if someone changes i to be some kind of constness backdoor. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 16:51 ` G.B. @ 2017-02-09 16:59 ` reinkor 2017-02-09 17:17 ` Dmitry A. Kazakov 2017-02-09 18:46 ` Niklas Holsti 1 sibling, 1 reply; 14+ messages in thread From: reinkor @ 2017-02-09 16:59 UTC (permalink / raw) On Thursday, February 9, 2017 at 5:51:46 PM UTC+1, G.B. wrote: > On 09.02.17 13:46, reinkor wrote: > > OK, I here try to communicate my intention via this simple example: > > > > i : Constant Integer := 5; -- all OK so far (but someone could > > change this to a variable) > > > > You could try making it more difficult for programmers > you seemingly need to fight in source text by > > - by making i a function; hide its body, > - make your code depend on compile time static constants. > > I'd suggest that it is time, technically, for your boss > or for yourself to call for discipline, or ask you lawyer > about what your contracts require you to guarantee if > someone changes i to be some kind of constness backdoor. Maybe SPARK has an answer. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 16:59 ` reinkor @ 2017-02-09 17:17 ` Dmitry A. Kazakov 2017-02-09 17:31 ` G.B. 0 siblings, 1 reply; 14+ messages in thread From: Dmitry A. Kazakov @ 2017-02-09 17:17 UTC (permalink / raw) On 2017-02-09 17:59, reinkor wrote: > On Thursday, February 9, 2017 at 5:51:46 PM UTC+1, G.B. wrote: >> On 09.02.17 13:46, reinkor wrote: >>> OK, I here try to communicate my intention via this simple example: >>> >>> i : Constant Integer := 5; -- all OK so far (but someone could >>> change this to a variable) >>> >> >> You could try making it more difficult for programmers >> you seemingly need to fight in source text by >> >> - by making i a function; hide its body, >> - make your code depend on compile time static constants. >> >> I'd suggest that it is time, technically, for your boss >> or for yourself to call for discipline, or ask you lawyer >> about what your contracts require you to guarantee if >> someone changes i to be some kind of constness backdoor. > > Maybe SPARK has an answer. Rather the OS. Set the ads file read-only. Calculate its signature (of military-grade length). Store the signature on an encrypted flash drive protected by biometric scanner. Verify the signature each 5 seconds to detect malicious source code modifications by intruders... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 17:17 ` Dmitry A. Kazakov @ 2017-02-09 17:31 ` G.B. 0 siblings, 0 replies; 14+ messages in thread From: G.B. @ 2017-02-09 17:31 UTC (permalink / raw) On 09.02.17 18:17, Dmitry A. Kazakov wrote: >> Maybe SPARK has an answer. > > Rather the OS. Set the ads file read-only. Calculate its signature (of military-grade length). Store the signature on an encrypted flash drive protected by biometric scanner. Verify the signature each 5 seconds to detect malicious source code modifications by intruders... Alternatively, you could store each line of source text in a DBMS that offers access control to rows, or if each spec lives in a separate table, to tables, etc. Then, have rights grated to team members accordingly. If working on Windows™, the object based UAC system could be used for associating rights with file objects, per user. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 16:51 ` G.B. 2017-02-09 16:59 ` reinkor @ 2017-02-09 18:46 ` Niklas Holsti 2017-02-10 7:48 ` reinkor 1 sibling, 1 reply; 14+ messages in thread From: Niklas Holsti @ 2017-02-09 18:46 UTC (permalink / raw) On 17-02-09 18:51 , G.B. wrote: > On 09.02.17 13:46, reinkor wrote: >> OK, I here try to communicate my intention via this simple example: >> >> i : Constant Integer := 5; -- all OK so far (but someone could >> change this to a variable) >> > > You could try making it more difficult for programmers > you seemingly need to fight in source text by > > - by making i a function; hide its body, > - make your code depend on compile time static constants. > > I'd suggest that it is time, technically, for your boss > or for yourself to call for discipline, or ask you lawyer > about what your contracts require you to guarantee if > someone changes i to be some kind of constness backdoor. I think I see a valid point in the OP's question. One can imagine a program in which a package A supplies a value ("i" in the example), and in which another, loosely related package B, perhaps in quite another part of the program, implements an algorithm that logically depends on this value never changing (after elaboration). It would be nice to be able to express this inter-package constancy constraint somehow, at compile time, as a guard against future mistakes in program evolution that might make the value non-constant and so destroy the logical basis for the algorithm in package B. At present, it seems to me that Ada offers only two ways to do this. The first way is to make the constant a named number in A, or a constant with a static value, and make a copy as a named number in B. Like this: package A is I : constant Integer := 5; -- A named number or (as here) a constant with a static value. end A; with A; package B is My_I : constant := A.I; -- A named number. This does not compile if A.I is non-constant, -- or has a non-static value (even if constant). end B; However, this only works if the type of the constant is numeric. The second way is just to document the reasons for the object being declared constant, at the point of that declaration: package A is I : constant Integer := 5; -- This must be a constant, because package B etc. etc. end A; I see less reason for a run-time check of constancy. However, there is a similar thing in Ada: the attribute 'Constrained. Perhaps there would be some interest in an attribute 'Constant, which could be applied to any object or named number and would be True for named numbers and constant objects, and only for those. On first look, it seems very simple to implement (but perhaps there is some complication in shared-code generics...) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 18:46 ` Niklas Holsti @ 2017-02-10 7:48 ` reinkor 0 siblings, 0 replies; 14+ messages in thread From: reinkor @ 2017-02-10 7:48 UTC (permalink / raw) You saved me :-) reinert On Thursday, February 9, 2017 at 7:46:03 PM UTC+1, Niklas Holsti wrote: > On 17-02-09 18:51 , G.B. wrote: > > On 09.02.17 13:46, reinkor wrote: > >> OK, I here try to communicate my intention via this simple example: > >> > >> i : Constant Integer := 5; -- all OK so far (but someone could > >> change this to a variable) > >> > > > > You could try making it more difficult for programmers > > you seemingly need to fight in source text by > > > > - by making i a function; hide its body, > > - make your code depend on compile time static constants. > > > > I'd suggest that it is time, technically, for your boss > > or for yourself to call for discipline, or ask you lawyer > > about what your contracts require you to guarantee if > > someone changes i to be some kind of constness backdoor. > > I think I see a valid point in the OP's question. One can imagine a > program in which a package A supplies a value ("i" in the example), and > in which another, loosely related package B, perhaps in quite another > part of the program, implements an algorithm that logically depends on > this value never changing (after elaboration). It would be nice to be > able to express this inter-package constancy constraint somehow, at > compile time, as a guard against future mistakes in program evolution > that might make the value non-constant and so destroy the logical basis > for the algorithm in package B. > > At present, it seems to me that Ada offers only two ways to do this. > > The first way is to make the constant a named number in A, or a constant > with a static value, and make a copy as a named number in B. Like this: > > package A is > I : constant Integer := 5; > -- A named number or (as here) a constant with a static value. > end A; > > with A; > package B is > My_I : constant := A.I; > -- A named number. This does not compile if A.I is non-constant, > -- or has a non-static value (even if constant). > end B; > > However, this only works if the type of the constant is numeric. > > The second way is just to document the reasons for the object being > declared constant, at the point of that declaration: > > package A is > I : constant Integer := 5; > -- This must be a constant, because package B etc. etc. > end A; > > I see less reason for a run-time check of constancy. However, there is a > similar thing in Ada: the attribute 'Constrained. Perhaps there would be > some interest in an attribute 'Constant, which could be applied to any > object or named number and would be True for named numbers and constant > objects, and only for those. On first look, it seems very simple to > implement (but perhaps there is some complication in shared-code > generics...) > > -- > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 12:46 ` reinkor ` (2 preceding siblings ...) 2017-02-09 16:51 ` G.B. @ 2017-02-09 18:03 ` Jeffrey R. Carter 3 siblings, 0 replies; 14+ messages in thread From: Jeffrey R. Carter @ 2017-02-09 18:03 UTC (permalink / raw) On 02/09/2017 01:46 PM, reinkor wrote: > > i : Constant Integer := 5; -- all OK so far (but someone could > change this to a variable) If someone changes it to a variable, presumably it's because of a logic change in which it can no longer be constant. There would then be further changes to the code to make use of its new variability. In the process, the person making the change would come across your test and remove it, since it's no longer relevant. So I don't see that such a test would buy you anything. If you have someone going around changing constants to variables for no reason, I suggest you no longer make use of that person's services. -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus 54 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Test for constant (or "in parameter" in procedure) 2017-02-09 4:38 Test for constant (or "in parameter" in procedure) reinkor 2017-02-09 12:11 ` AdaMagica @ 2017-03-26 20:57 ` Norman Worth 1 sibling, 0 replies; 14+ messages in thread From: Norman Worth @ 2017-03-26 20:57 UTC (permalink / raw) reinkor wrote: > Hi, > > is it a good way to test if an object is a constant or not (or "in parameter" in a procedure)? Something in addition to declare it as a constant? > > If I am sure an object is a constant (and can check it) then this can sometimes help to structure/optimize the code. I would like to have some redundancy and make sure an object is really constant when this is a prerequisite for a piece of code to be according to my intentions - i.e. if the object is messed with somewhere, then things could go wrong. So I would like some "local check" to be sure a constant is really a constant :-) Specially if many people are involved to change code over time. > > reinert > This might best be handled by a comment warning that the constant must be a constant (or in parameter) because of its later use. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-03-26 20:57 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-09 4:38 Test for constant (or "in parameter" in procedure) reinkor 2017-02-09 12:11 ` AdaMagica 2017-02-09 12:46 ` reinkor 2017-02-09 13:09 ` Dmitry A. Kazakov 2017-02-09 14:10 ` AdaMagica 2017-02-09 15:01 ` reinkor 2017-02-09 16:51 ` G.B. 2017-02-09 16:59 ` reinkor 2017-02-09 17:17 ` Dmitry A. Kazakov 2017-02-09 17:31 ` G.B. 2017-02-09 18:46 ` Niklas Holsti 2017-02-10 7:48 ` reinkor 2017-02-09 18:03 ` Jeffrey R. Carter 2017-03-26 20:57 ` Norman Worth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox