From: Hibou57 (Yannick Duchêne) on
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.

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).
From: Hibou57 (Yannick Duchêne) on
On 30 jan, 03:42, "Randy Brukardt" <ra...(a)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).
From: Adam Beneschan on
On Jan 29, 6:42 pm, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote:
> "Robert A Duff" <bobd...(a)shell01.TheWorld.com> wrote in messagenews:wccy6jkz46l.fsf(a)shell01.TheWorld.com...
>
> > "Hibou57 (Yannick Duchêne)" <yannick_duch...(a)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
From: Hibou57 (Yannick Duchêne) on
On 2 fév, 22:26, Adam Beneschan <a...(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).
From: Adam Beneschan on
On Feb 2, 1:47 pm, Hibou57 (Yannick Duchêne)
<yannick_duch...(a)yahoo.fr> wrote:
> On 2 fév, 22:26, Adam Beneschan <a...(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