Prev: More of less most standard Ada binding to POSIX
Next: Can Someone please help me with my Computer stuff? 05162
From: Hibou57 (Yannick Duchêne) on 26 Jan 2010 20:57
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 ?
From: Robert A Duff on 26 Jan 2010 21:12
"Hibou57 (Yannick Duch�ne)" <yannick_duchene(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.

- Bob
From: Hibou57 (Yannick Duchêne) on 26 Jan 2010 21:15
On 27 jan, 03:12, Robert A Duff <bobd...(a)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 ...
From: Randy Brukardt on 29 Jan 2010 21:42
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message
news:wccy6jkz46l.fsf(a)shell01.TheWorld.com...
> "Hibou57 (Yannick Duch�ne)" <yannick_duchene(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.)

Randy.


From: AdaMagica on 30 Jan 2010 03:45
> 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;
 |  Next  |  Last
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