Constant as anonymous functions : the outer space beast is back

Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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 ?

Re: Constant as anonymous functions : the outer space beast is back

[Robert A Duff]

"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

Re: Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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 ...

Re: Constant as anonymous functions : the outer space beast is back

[Randy Brukardt]

[-- 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.

Re: Constant as anonymous functions : the outer space beast is back

[AdaMagica]

> 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;

Re: Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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).

Re: Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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).

Re: Constant as anonymous functions : the outer space beast is back

[Adam Beneschan]

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

Re: Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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).

Re: Constant as anonymous functions : the outer space beast is back

[Adam Beneschan]

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

Re: Constant as anonymous functions : the outer space beast is back

[Randy Brukardt]

[-- 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.

Re: Constant as anonymous functions : the outer space beast is back

[Hibou57 (Yannick Duchêne)]

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

Re: Constant as anonymous functions : the outer space beast is back

[Dmitry A. Kazakov]

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

Re: Constant as anonymous functions : the outer space beast is back

[Robert A Duff]

"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

Re: Constant as anonymous functions : the outer space beast is back

[Randy Brukardt]

[-- 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.