* Constant as anonymous functions : the outer space beast is back @ 2010-01-27 1:57 Hibou57 (Yannick Duchêne) 2010-01-27 2:12 ` Robert A Duff 0 siblings, 1 reply; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-01-27 1:57 UTC (permalink / raw) Hi, I'm back with the topic “ constant as anonymous functions ” ( I've opened last year, about 10 months ago if my mind is right ) with a new argument advocating for it : I have a simple design rule which state that I automatically add a “ pragma Elaborate_Body ” in the heading of a package specification, as soon as this package defines functions which have the semantic of constants, because dependencies to the specifications as supposed to be possible dependencies to these “ constants ”, and as elaboration of these “ constants ” requires body elaboration, a dependency to such a package specification is supposed to probably requires body elaboration. Here we are : the lack of constants as anonymous functions turn into consequences on the package elaboration order. That's big (at least to me). Another argument : enabling constants to be anonymous functions would allow to change a functions into a constant without breaking anything, unlike what is in the actual state. Actually, there seems to be a kind of implementation dependency in specifications due to the lack of constants as functions. Third, but already pointed (as I remember) when the topic was opened about ten months ago : this would not break any existing sources and designs. Who want to talk about this subject ? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-27 1:57 Constant as anonymous functions : the outer space beast is back Hibou57 (Yannick Duchêne) @ 2010-01-27 2:12 ` Robert A Duff 2010-01-27 2:15 ` Hibou57 (Yannick Duchêne) 2010-01-30 2:42 ` Randy Brukardt 0 siblings, 2 replies; 15+ messages in thread From: Robert A Duff @ 2010-01-27 2:12 UTC (permalink / raw) "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes: > I'm back with the topic constant as anonymous functions ( I've > opened last year, about 10 months ago if my mind is right ) ... ... > Who want to talk about this subject ? Umm... Maybe you should tell us all what you mean by "constant as anonymous functions", or quote your 10-month-old ideas, just in case some of us have forgotten, or missed it the first time around. - Bob ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-27 2:12 ` Robert A Duff @ 2010-01-27 2:15 ` Hibou57 (Yannick Duchêne) 2010-01-30 2:42 ` Randy Brukardt 1 sibling, 0 replies; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-01-27 2:15 UTC (permalink / raw) On 27 jan, 03:12, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: > Umm... Maybe you should tell us all what you mean by > "constant as anonymous functions", or quote your 10-month-old > ideas, just in case some of us have forgotten, or missed it > the first time around. May be this was not the good word : implicit functions ? Like are item of enumerations ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-27 2:12 ` Robert A Duff 2010-01-27 2:15 ` Hibou57 (Yannick Duchêne) @ 2010-01-30 2:42 ` Randy Brukardt 2010-01-30 8:45 ` AdaMagica ` (2 more replies) 1 sibling, 3 replies; 15+ messages in thread From: Randy Brukardt @ 2010-01-30 2:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2780 bytes --] "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccy6jkz46l.fsf@shell01.TheWorld.com... > "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes: > >> I'm back with the topic constant as anonymous functions ( I've >> opened last year, about 10 months ago if my mind is right ) ... > ... >> Who want to talk about this subject ? > > Umm... Maybe you should tell us all what you mean by > "constant as anonymous functions", or quote your 10-month-old > ideas, just in case some of us have forgotten, or missed it > the first time around. I think he's talking about making constants overloadable, so that they resolve like functions. This sounds suspiciously similar to something that one of your esteamed colleagues (me) suggested in the last couple of weeks. The idea didn't get much traction, however. Specifically, I was proposing that use clauses treat objects as overloadable, rather than causing cancelation semantics. This would reduce the maintenance hazard of use clauses (caused when the addition of unrelated declarations causes existing code to fail to compile). The subject came up within the context of "integrated packages", which have the effect of forcing the problems of use clauses on clients whether they like it or not. I was trying to mitigate that danger. Anyway, I wasn't trying to suggest that we go any further than that, as (arguably) there is a significant readability decrease if you apply overloading to all object references everywhere. The issue is that local objects would no longer hide distant ones, meaning that determining the actual item denoted by a name would be much harder. I'm not sure if this is really an important issue or not, but I would expect it to be used to derail any attempt at an overall change. Specifically, consider something like the following if overloading was allowed for objects: package P is Count : constant Float := 10; end P; with P; use P; with Ada.Float_Text_IO; procedure Do_It is Result : Float := 0.0; begin for Count in 1 .. 10 loop Result := Result + Count; end loop; Ada.Float_Text_IO.Put(Result); end Do_It; This program would print 100.0 if objects (or just constants for that matter) had full overloading; it is illegal in Ada today (because of the type error). Probably the programmer expects a result of 55.0, and would be quite surprised that they didn't get it. It would take a long time to realize that Count does not denote the object directly declared on the previous line! (Even if you were aware of this possibility, you'd probably think many other things were wrong before checking to see if the problem is in the interpretation of Count.) Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-30 2:42 ` Randy Brukardt @ 2010-01-30 8:45 ` AdaMagica 2010-02-02 19:34 ` Hibou57 (Yannick Duchêne) 2010-02-02 19:36 ` Hibou57 (Yannick Duchêne) 2010-02-02 21:26 ` Adam Beneschan 2 siblings, 1 reply; 15+ messages in thread From: AdaMagica @ 2010-01-30 8:45 UTC (permalink / raw) > package P is > Count : constant Float := 10; > end P; And even if you make Count a function (overloadable), this example code is still illegal in Ada as is - and that's a good thing. package P is function Count return Float; end P; ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-30 8:45 ` AdaMagica @ 2010-02-02 19:34 ` Hibou57 (Yannick Duchêne) 2010-02-05 21:51 ` Randy Brukardt 2010-02-07 16:22 ` Robert A Duff 0 siblings, 2 replies; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-02-02 19:34 UTC (permalink / raw) On 30 jan, 09:45, AdaMagica <christoph.gr...@eurocopter.com> wrote: > And even if you make Count a function (overloadable), this example > code is still illegal in Ada as is - and that's a good thing. > > package P is > function Count return Float; > end P; Yes, because the Count loop variant still hide the one from P. That's the proof there would be no bad side effects to make the “ equivalent ” constant overloadable the same way. If it's not good for constants, so why should it be good for functions ? Reciprocally, if it's Ok for functions, why wouldn't it be good for constants ? What's the rational underlying this distinction between constants as functions ? Isn't it just a matter of implementation after all ? I see implementation differences, no any semantic ones (I know some implementation choices have legitimately semantic side effects, but this one should not, unless there are opposite arguments which I do not know about). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-02 19:34 ` Hibou57 (Yannick Duchêne) @ 2010-02-05 21:51 ` Randy Brukardt 2010-02-05 22:41 ` Hibou57 (Yannick Duchêne) 2010-02-07 16:22 ` Robert A Duff 1 sibling, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2010-02-05 21:51 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2272 bytes --] "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message news:454c900f-85ed-4a40-ad13-a5b432261b99@c29g2000yqd.googlegroups.com... >On 30 jan, 09:45, AdaMagica <christoph.gr...@eurocopter.com> wrote: >> And even if you make Count a function (overloadable), this example >> code is still illegal in Ada as is - and that's a good thing. >> >> package P is >> function Count return Float; >> end P; > >Yes, because the Count loop variant still hide the one from P. Right, but that wouldn't be true in your suggested semantics, as the Count object would be overloadable. Even if you restricted that only to constants (of which Count is one). It's clear that you haven't thought this through very well. Adam notes that you could just change the behavior of constants declared with "constant", but that makes no sense -- a renames of a constant object does not include the keyword constant. So such a "simple" rule wouldn't work. Moreover, it doesn't make sense to treat constants and variables differently. The only sane choice is to change the behavior of *all* objects -- there is nothing that special about constants. Treating constants and variables differently would introduce a major maintenance hazard. The current principle (and one that ever programmer would expect) is that changing a declaration from constant to variable (or the reverse) only changes whether or not it can be written. Otherwise it ought to behave identically. Making the visibility rules wildly different for constants and variables would not have that effect (it's quite likely changing a constant to a variable would make some if it's uses illegal using your rule). And it is bizarre to say that you are trying to increase consistency and then try to treat things syntactically declared one way from equivalent things declared in another way. How that could *increase* consistency is beyond my comprehension. I had seriously proposed making objects overloadable declarations for use clause purposes only (mainly to decrease the maintenance hazard inherent in use clauses - which is really what you are complaining about), but that idea didn't get any traction. So nothing is going to change in this area. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-05 21:51 ` Randy Brukardt @ 2010-02-05 22:41 ` Hibou57 (Yannick Duchêne) 2010-02-06 9:34 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-02-05 22:41 UTC (permalink / raw) On 5 fév, 22:51, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > Right, but that wouldn't be true in your suggested semantics, as the Count > object would be overloadable. Even if you restricted that only to constants > (of which Count is one). As you noticed later, Adam better expressed my implicit though, when he talked about the Constant keyword, so this wouldn't apply the Count of the example. > It's clear that you haven't thought this through very well. Adam notes > that you could just change the behavior of constants declared with > "constant", but that makes no sense -- a renames of a constant object > does not include the keyword constant. So such a "simple" rule > wouldn't work. I confess the rename case is a thorn there. Good or bad, by the way ? I not aware enough of some rationale, but I feel the Constant keyword should be part of Constant renaming. I'm not to suggest about it, I'm just noticing. > Moreover, it doesn't make sense to treat constants and variables > differently. Does it make more sens to treat functions without parameter and constants differently ? > The only sane choice is to change the behavior of *all* > objects -- there is nothing that special about constants. Treating constants > and variables differently would introduce a major maintenance hazard. The > current principle (and one that ever programmer would expect) is that > changing a declaration from constant to variable (or the reverse) only > changes whether or not it can be written. My concurrent though was that programmer could expect that changing a declaration from constant to pure function only change the implementation. > Otherwise it ought to behave > identically. Making the visibility rules wildly different for constants and > variables would not have that effect (it's quite likely changing a constant > to a variable would make some if it's uses illegal using your rule). Semantically, a constant is not a variable. Whenever you change a constant to a variable, you are changing either the semantic or the specification. This objection is thus unsuitable to me. There is no legitimate reason to change a constant into a variable, unless you are changing the specification (and in turn, everything relying on it should be revised anyway). While changing a constant into a function could be legitimate (this is just changing the implementation, not the specification). Why would you turn a constant into a variable, unless you are changing some specifications ? > And it is bizarre to say that you are trying to increase consistency and > then try to treat things syntactically declared one way from equivalent > things declared in another way. How that could *increase* consistency is > beyond my comprehension. Indeed, nothing is guaranteeing I'm right. > I had seriously proposed making objects overloadable declarations for use > clause purposes only (mainly to decrease the maintenance hazard inherent in > use clauses - which is really what you are complaining about), I don't have any trouble with Use clauses, I am never Using. > but that idea > didn't get any traction. So nothing is going to change in this area. > > Randy. I'm not aware of ADA Issues news (I use to receive it, but gave up as there was too much mails to me), but I may have a look at what you are talking about. Thanks for your comments ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-05 22:41 ` Hibou57 (Yannick Duchêne) @ 2010-02-06 9:34 ` Dmitry A. Kazakov 0 siblings, 0 replies; 15+ messages in thread From: Dmitry A. Kazakov @ 2010-02-06 9:34 UTC (permalink / raw) On Fri, 5 Feb 2010 14:41:50 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: > On 5 f�v, 22:51, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> It's clear that you haven't thought this through very well. Adam notes >> that you could just change the behavior of constants declared with >> "constant", but that makes no sense -- a renames of a constant object >> does not include the keyword constant. So such a "simple" rule >> wouldn't work. > I confess the rename case is a thorn there. > > Good or bad, by the way ? > > I not aware enough of some rationale, but I feel the Constant keyword > should be part of Constant renaming. Possibly, however, obviously, anything that appears in a renaming beyond the names is a noise. It is present in order to hint what is going to be renamed in presence of potential overloading. From that point of view, yes, allowing overloaded constants could require more noise. >> Moreover, it doesn't make sense to treat constants and variables >> differently. > Does it make more sens to treat functions without parameter and > constants differently ? However, there is a tricky semantic issue. When you refer to a function, do you to the object of, or else to the object of the function result evaluated on the current context? Is it lazy or eager? Since pure functions are still "not Ada", it is dangerous to introduce this sort of equivalence you propose. Only a pure function [pure relatively to the contexts where it is evaluated] is equivalent to a constant. And further if some day functions to become first-class citizens in Ada, things will be even more complicated. >> Otherwise it ought to behave >> identically. Making the visibility rules wildly different for constants and >> variables would not have that effect (it's quite likely changing a constant >> to a variable would make some if it's uses illegal using your rule). > Semantically, a constant is not a variable. No, surely it is. Semantically a constant of the type T refers to an object (maybe transient) of a subtype of T, such that all mutating operations are disallowed. Variable of the type T refers to an object of the type T. The only difference is in the types: T vs. "constant T" (officially, Ada does not have constant subtypes) That a constant object can be transient is an implementation detail. > I don't have any trouble with Use clauses, I am never Using. Well, there are many "use"-haters among Ada people. (:-)) I am a "with"-hater. I prefer to design the packages, so that one could use plain names. Unfortunately there are many problems with that because of generics and lacking means to inherit the declarative region of another package. The latter will probably be addressed in Ada 2015. The former only will be if we abolish generics. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-02 19:34 ` Hibou57 (Yannick Duchêne) 2010-02-05 21:51 ` Randy Brukardt @ 2010-02-07 16:22 ` Robert A Duff 2010-02-09 0:22 ` Randy Brukardt 1 sibling, 1 reply; 15+ messages in thread From: Robert A Duff @ 2010-02-07 16:22 UTC (permalink / raw) "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes: > If it's not good for constants, so why should it be good for > functions ? You're right -- it would make sense to allow overloading for constants. In fact, it would make sense to allow overloading for everything. But you'd want to make the resolution rules weak, so that anything that is likely to be confusing to programmers would be ambiguous and therefore illegal. Ada's resolution rules are too strong as it is. For example: F(...).all := X; I find it odd that the type of X is used to resolve which F you're calling. Another point: implicit hiding is evil. It causes Beaujolais-like effects. Ada 95 makes it worse, because of child packages -- the hiding can cross library unit boundaries. Subunits already had similar problems in Ada 83, but subunits are less useful, and therefore rarer, than child packages. - Bob ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-07 16:22 ` Robert A Duff @ 2010-02-09 0:22 ` Randy Brukardt 0 siblings, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2010-02-09 0:22 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1735 bytes --] "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccvde9audf.fsf@shell01.TheWorld.com... > "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes: > >> If it's not good for constants, so why should it be good for >> functions ? > > You're right -- it would make sense to allow overloading for constants. > In fact, it would make sense to allow overloading for everything. > But you'd want to make the resolution rules weak, so that anything > that is likely to be confusing to programmers would be ambiguous and > therefore illegal. > > Ada's resolution rules are too strong as it is. For example: > > F(...).all := X; > > I find it odd that the type of X is used to resolve which > F you're calling. > > Another point: implicit hiding is evil. It causes Beaujolais-like > effects. Ada 95 makes it worse, because of child packages -- the > hiding can cross library unit boundaries. Subunits already had > similar problems in Ada 83, but subunits are less useful, and > therefore rarer, than child packages. I agree with Bob here. Hibou57 (Yannick Duch�ne) <yannick_duchene@yahoo.fr> writes: > I not aware enough of some rationale, but I feel the Constant keyword > should be part of Constant renaming. And I agree with you here. In both cases if we were starting from scratch. But we're not starting from scratch. There are millions on lines of existing Ada code. Fixing these things would be very incompatible. We've been trying to find ways to compatibly fix issues with subprogram renames for years, but it isn't easy and is dubious if it really is helpful. The net effect is that most likely, there will be little or no change in these areas. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-30 2:42 ` Randy Brukardt 2010-01-30 8:45 ` AdaMagica @ 2010-02-02 19:36 ` Hibou57 (Yannick Duchêne) 2010-02-02 21:26 ` Adam Beneschan 2 siblings, 0 replies; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-02-02 19:36 UTC (permalink / raw) On 30 jan, 03:42, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > if you apply > overloading to all object references everywhere. The issue is that local > objects would no longer hide distant ones That's the part I don't understand. AdaMagica has shown it is not (and as he/she said, that's indeed a good thing the example construct is not legal Ada source text). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-01-30 2:42 ` Randy Brukardt 2010-01-30 8:45 ` AdaMagica 2010-02-02 19:36 ` Hibou57 (Yannick Duchêne) @ 2010-02-02 21:26 ` Adam Beneschan 2010-02-02 21:47 ` Hibou57 (Yannick Duchêne) 2 siblings, 1 reply; 15+ messages in thread From: Adam Beneschan @ 2010-02-02 21:26 UTC (permalink / raw) On Jan 29, 6:42 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote in messagenews:wccy6jkz46l.fsf@shell01.TheWorld.com... > > > "Hibou57 (Yannick Duchêne)" <yannick_duch...@yahoo.fr> writes: > > >> I'm back with the topic constant as anonymous functions ( I've > >> opened last year, about 10 months ago if my mind is right ) ... > > ... > >> Who want to talk about this subject ? > > > Umm... Maybe you should tell us all what you mean by > > "constant as anonymous functions", or quote your 10-month-old > > ideas, just in case some of us have forgotten, or missed it > > the first time around. > > I think he's talking about making constants overloadable, so that they > resolve like functions. This sounds suspiciously similar to something that > one of your esteamed colleagues (me) suggested in the last couple of weeks. > The idea didn't get much traction, however. > > Specifically, I was proposing that use clauses treat objects as > overloadable, rather than causing cancelation semantics. This would reduce > the maintenance hazard of use clauses (caused when the addition of unrelated > declarations causes existing code to fail to compile). The subject came up > within the context of "integrated packages", which have the effect of > forcing the problems of use clauses on clients whether they like it or not. > I was trying to mitigate that danger. > > Anyway, I wasn't trying to suggest that we go any further than that, as > (arguably) there is a significant readability decrease if you apply > overloading to all object references everywhere. The issue is that local > objects would no longer hide distant ones, meaning that determining the > actual item denoted by a name would be much harder. I'm not sure if this is > really an important issue or not, but I would expect it to be used to derail > any attempt at an overall change. > > Specifically, consider something like the following if overloading was > allowed for objects: > > package P is > Count : constant Float := 10; > end P; > > with P; use P; > with Ada.Float_Text_IO; > procedure Do_It is > Result : Float := 0.0; > begin > for Count in 1 .. 10 loop > Result := Result + Count; > end loop; > Ada.Float_Text_IO.Put(Result); > end Do_It; > > This program would print 100.0 if objects (or just constants for that > matter) had full overloading; it is illegal in Ada today (because of the > type error). Probably the programmer expects a result of 55.0, and would be > quite surprised that they didn't get it. It would take a long time to > realize that Count does not denote the object directly declared on the > previous line! (Even if you were aware of this possibility, you'd probably > think many other things were wrong before checking to see if the problem is > in the interpretation of Count.) Some problems like that could be mitigated by defining overloading only for constants declared with an <object-declaration> that contains the word "constant". I.e. *not* for loop variables, IN parameters, exception occurrence variables in handlers, .............. Actually, I suspect that that's the kind of constant the OP was thinking of, not everything that the language defines as having a constant view. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-02 21:26 ` Adam Beneschan @ 2010-02-02 21:47 ` Hibou57 (Yannick Duchêne) 2010-02-03 0:55 ` Adam Beneschan 0 siblings, 1 reply; 15+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2010-02-02 21:47 UTC (permalink / raw) On 2 fév, 22:26, Adam Beneschan <a...@irvine.com> wrote: > Some problems like that could be mitigated by defining overloading > only for constants declared with an <object-declaration> that contains > the word "constant". I.e. *not* for loop variables, IN parameters, > exception occurrence variables in handlers, .............. Actually, > I suspect that that's the kind of constant the OP was thinking of, not > everything that the language defines as having a constant view. > > -- Adam If I'm the OP you were referring to, yes, I was meaning the constants declared with the keyword Constant, not everything which have a constant view. ..... what's an OP ? ... please Later words : to be honest, although it would be conceptually cleaner, this tiny lack is not as much a pain. There is the function workaround which is just a bit more text lines to write. The reason why I've introduced this topic, is because of the side two effects which comes with it : required body for specifications which would not requires a body otherwise and body elaboration required to access the full specification. I did not meet, my self, any trouble with it, I was just anticipating based on logical assumptions (I know in some circumstance, elaboration order may be an issue, as well as may be the existence of a body which some requirements may exclude). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Constant as anonymous functions : the outer space beast is back 2010-02-02 21:47 ` Hibou57 (Yannick Duchêne) @ 2010-02-03 0:55 ` Adam Beneschan 0 siblings, 0 replies; 15+ messages in thread From: Adam Beneschan @ 2010-02-03 0:55 UTC (permalink / raw) On Feb 2, 1:47 pm, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr> wrote: > On 2 fév, 22:26, Adam Beneschan <a...@irvine.com> wrote: > > > Some problems like that could be mitigated by defining overloading > > only for constants declared with an <object-declaration> that contains > > the word "constant". I.e. *not* for loop variables, IN parameters, > > exception occurrence variables in handlers, .............. Actually, > > I suspect that that's the kind of constant the OP was thinking of, not > > everything that the language defines as having a constant view. > > > -- Adam > > If I'm the OP you were referring to, yes, I was meaning the constants > declared with the keyword Constant, not everything which have a > constant view. > > ..... what's an OP ? ... please "original poster" -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-02-09 0:22 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-01-27 1:57 Constant as anonymous functions : the outer space beast is back Hibou57 (Yannick Duchêne) 2010-01-27 2:12 ` Robert A Duff 2010-01-27 2:15 ` Hibou57 (Yannick Duchêne) 2010-01-30 2:42 ` Randy Brukardt 2010-01-30 8:45 ` AdaMagica 2010-02-02 19:34 ` Hibou57 (Yannick Duchêne) 2010-02-05 21:51 ` Randy Brukardt 2010-02-05 22:41 ` Hibou57 (Yannick Duchêne) 2010-02-06 9:34 ` Dmitry A. Kazakov 2010-02-07 16:22 ` Robert A Duff 2010-02-09 0:22 ` Randy Brukardt 2010-02-02 19:36 ` Hibou57 (Yannick Duchêne) 2010-02-02 21:26 ` Adam Beneschan 2010-02-02 21:47 ` Hibou57 (Yannick Duchêne) 2010-02-03 0:55 ` Adam Beneschan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox