Prev: More of less most standard Ada binding to POSIX
Next: Can Someone please help me with my Computer stuff? 05162
From: Randy Brukardt on 5 Feb 2010 16:51
"Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> wrote in message
news:454c900f-85ed-4a40-ad13-a5b432261b99(a)c29g2000yqd.googlegroups.com...
>On 30 jan, 09:45, AdaMagica <christoph.gr...(a)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.





From: Hibou57 (Yannick Duchêne) on 5 Feb 2010 17:41
On 5 fév, 22:51, "Randy Brukardt" <ra...(a)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
From: Dmitry A. Kazakov on 6 Feb 2010 04:34
On Fri, 5 Feb 2010 14:41:50 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 5 f�v, 22:51, "Randy Brukardt" <ra...(a)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
From: Robert A Duff on 7 Feb 2010 11:22
"Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)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
From: Randy Brukardt on 8 Feb 2010 19:22
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message
news:wccvde9audf.fsf(a)shell01.TheWorld.com...
> "Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)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(a)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.


First  |  Prev  | 
Pages: 1 2 3
Prev: More of less most standard Ada binding to POSIX
Next: Can Someone please help me with my Computer stuff? 05162