Functions vs constants

Functions vs constants

[Victor Porton]

Isn't the following a mis-design of Ada?

Constants in a good programming language should be equivalent to argument-
less functions which return these constants.

However, in Ada functions can be overloaded by their return type, while 
constants cannot.

Mad idea, but I propose it: Make in a future specification of Ada constants 
overloadable (moreover, make constants argument-less functions). (However I 
am not sure how this could affect reliability. But should we think about it 
at all? After all function overloading was not ruled out with the same 
requirements, and ruling this out as possibly unreliable would be a half-
measure.)

I wrote this post after a practical problem whether I should use a String 
constant or a function returning String to return the library version 
(related with a C library for which I am writing bindings). There are no 
definite answer to this question. It is in any case of wrong design.

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Victor Porton]

Victor Porton wrote:
> Isn't the following a mis-design of Ada?
> 
> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.
> 
> However, in Ada functions can be overloaded by their return type, while
> constants cannot.
> 
> Mad idea, but I propose it: Make in a future specification of Ada
> constants overloadable (moreover, make constants argument-less functions).
> (However I am not sure how this could affect reliability. But should we
> think about it at all? After all function overloading was not ruled out
> with the same requirements, and ruling this out as possibly unreliable
> would be a half- measure.)
> 
> I wrote this post after a practical problem whether I should use a String
> constant or a function returning String to return the library version
> (related with a C library for which I am writing bindings). There are no
> definite answer to this question. It is in any case of wrong design.

This would additionally allow to rename constants as functions.

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Shark8]

On 21-Jul-14 15:28, Victor Porton wrote:
> This would additionally allow to rename constants as functions.

You can already do that:

     package CPU is
         Type Register is (
                           -- General registers
                           EAX, EBX, ECX, EDX,

                           -- Segment registers
                           CS, DS, ES, FS, GS, SS,

                           -- Index and pointers
                           ESI, EDI, EBP, EIP, ESP,

                           --Indicator
                           EFLAGS
                          );

         function Default return Register;
     private
         function Default Return Register Renames EAX;
     end CPU;

Or
         function Default_User Return String is ("Dave");

Re: Functions vs constants

[Victor Porton]

Shark8 wrote:

> On 21-Jul-14 15:28, Victor Porton wrote:
>> This would additionally allow to rename constants as functions.
> 
> You can already do that:
> 
>      package CPU is
>          Type Register is (
>                            -- General registers
>                            EAX, EBX, ECX, EDX,
> 
>                            -- Segment registers
>                            CS, DS, ES, FS, GS, SS,
> 
>                            -- Index and pointers
>                            ESI, EDI, EBP, EIP, ESP,
> 
>                            --Indicator
>                            EFLAGS
>                           );
> 
>          function Default return Register;
>      private
>          function Default Return Register Renames EAX;
>      end CPU;

Enumeration literals are technically not constants, are them?

> Or
>          function Default_User Return String is ("Dave");
-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Adam Beneschan]

On Monday, July 21, 2014 2:52:14 PM UTC-7, Victor Porton wrote:

> Enumeration literals are technically not constants, are them?

They are functions.  See RM 3.5.1(6).  However, they are considered "static functions" and can thus appear in some places where static values are expected.  (Saying it's a "static value" is stronger than saying it's a constant; a static value is a constant but it's also one that the compiler can figure out when compiling.)

                                 -- Adam

Re: Functions vs constants

[Niklas Holsti]

On 14-07-22 00:18 , Victor Porton wrote:
> Isn't the following a mis-design of Ada?
> 
> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.

Possibly, for some personal concept of "good".

> However, in Ada functions can be overloaded by their return type, while 
> constants cannot.
> 
> Mad idea

Why mad?

>, but I propose it: Make in a future specification of Ada constants 
> overloadable (moreover, make constants argument-less functions).

Others have also suggested this, and even wider overloading (including
variables). Arguments against the idea relied on subjective opinion, if
I remember correctly.

I do not see a pressing need to make constants (or variables)
overloadable. If I want to overload constants, I define overloaded
functions which return those constants. As for variables, they are
nearly always so local that overloading seems overkill.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Functions vs constants

[Victor Porton]

Niklas Holsti wrote:

> On 14-07-22 00:18 , Victor Porton wrote:
>> Isn't the following a mis-design of Ada?
>> 
>> Constants in a good programming language should be equivalent to
>> argument- less functions which return these constants.
> 
> Possibly, for some personal concept of "good".
> 
>> However, in Ada functions can be overloaded by their return type, while
>> constants cannot.
>> 
>> Mad idea
> 
> Why mad?

Because my idea looks like as something unreliable. (However it should not 
be quickly dismissed by this argument, because the same argument could apply 
to overloading functions.)

>>, but I propose it: Make in a future specification of Ada constants
>> overloadable (moreover, make constants argument-less functions).
> 
> Others have also suggested this, and even wider overloading (including
> variables). Arguments against the idea relied on subjective opinion, if
> I remember correctly.
> 
> I do not see a pressing need to make constants (or variables)
> overloadable. If I want to overload constants, I define overloaded
> functions which return those constants. As for variables, they are
> nearly always so local that overloading seems overkill.

The idea of overloading constants comes from the use case, when I have one 
constant and after revising my source code want to make two overloaded 
entities with that name instead of one. This would require me first to 
replace the existing constant with a function, and this step looks quite 
ridiculous for me (when I add something to the program, the old code should 
not need modifications).

I agree that overloading variables is an overkill. (And I do not know any 
language where vars can be overloaded.)

But the idea to make constants a kind of functions is viable.

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:c35fbuF747qU1@mid.individual.net...
> On 14-07-22 00:18 , Victor Porton wrote:
...
>>, but I propose it: Make in a future specification of Ada constants
>> overloadable (moreover, make constants argument-less functions).
>
> Others have also suggested this, and even wider overloading (including
> variables). Arguments against the idea relied on subjective opinion, if
> I remember correctly.

Right. I've worked out the implications (it was in relation to problems with 
an AI that was later dropped). It doesn't make sense to allow overloading of 
constants but not variables because the line between constants and variables 
is very fuzzy. And it doesn't matter anyway, as the problem in either case 
is one of compatibility. If one allows overloading, then some legal programs 
would become illegal (because of ambiguity, usually involving nesting), and 
worse, a very few programs would change meaning (because of use clauses). 
That's generally considered too dangerous to consider for Ada - certainly 
not without it fixing a major problem.

Otherwise, I think all objects (including exceptions) should allow 
overloading. Had that been done from the beginning, a lot of the maintenance 
hazards of use clauses would have been avoided (and my opinion of them would 
not be so negative). But it's too late now for Ada; perhaps if a new 
Ada-like language was constructed, it would be possible there.

[Note when I say "it's too late now", I mean that it's very unlikely that 
we'd have the will to make a change with such far-reaching consequences, all 
of which could never be understood. I have been surprised before (the fix to 
untagged record equality is a similar problem that I thought we'd never fix 
because of the compatibility concerns - but we did fix it in Ada 2012).]

                                       Randy.

Re: Functions vs constants

[Dmitry A. Kazakov]

On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote:

> Otherwise, I think all objects (including exceptions) should allow 
> overloading. 

What would be of exception renaming then? Would it create a new, possibly,
overloaded with itself object? That would be fun!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:cso9nzjs6q5q$.16o96j9yv70q1$.dlg@40tude.net...
> On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote:
>
>> Otherwise, I think all objects (including exceptions) should allow
>> overloading.
>
> What would be of exception renaming then? Would it create a new, possibly,
> overloaded with itself object? That would be fun!

??? I don't see a problem. Resolution works as it does now for subprograms, 
and either there is a unique resolution or not. No one says "what would be 
of function renaming if overloading is allowed" -- it just is and everything 
is fine.

The primary reason for allowing overloading of exceptions (as with objects) 
is so that they don't get hidden by something unrelated. (Especially a 
problem for use clauses.) If you have something like (assume these 
declarations have real names and the packages contain dozens of declarations 
each):

   package P is
       Error : Boolean;
   end P;
   package Q is
       Error : exception;
   end Q;

   with P, Q; use P, Q;
   procedure R is
   begin
       if Error then -- (1)
          raise Error; -- (2)
      end if;
   end R;

both (1) and (2) are illegal today. But there's no good reason for that; the 
profiles (imagining an extended idea of profile to include objects and 
exceptions) are different and there can be no more confusion between them 
than between overloaded enumeration literals.

If you've got entities with the same names and profiles in different 
packages, that's a problem that should be detected. But so long as the 
profiles are different (and that's almost always the case), then there 
shouldn't be a problem (which is not the case today).

A thought just popped into my head, perhaps you are worrying about:
    Name_Error : exception renames IO_Exceptions.Name_Error;
This is thought by many to be a long time bug in Ada. If you have "use 
Text_IO, IO_Exceptions;" then "raise Name_Error;" is illegal -- but that's 
silly because both possibilities are the same entity.

That could be fixed by adopting a rule such that if the only reason that a 
name is ambiguious is because it resolved to several different views of the 
same entity, that it would be treated as properly resolved to the entity. 
The only thing the compiler (or reader, for that matter) need care about is 
underlying entity, not exactly which view is involved. That would be 
additional complication in the language rules, but an Ada programmer would 
almost never care about it.

In any case, this isn't necessary to support object and exception 
overloading; it would help some, but more importantly it's probably a good 
idea on its own.

                                    Randy.

Re: Functions vs constants

[Dmitry A. Kazakov]

On Tue, 22 Jul 2014 17:07:55 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:cso9nzjs6q5q$.16o96j9yv70q1$.dlg@40tude.net...
>> On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote:
>>
>>> Otherwise, I think all objects (including exceptions) should allow
>>> overloading.
>>
>> What would be of exception renaming then? Would it create a new, possibly,
>> overloaded with itself object? That would be fun!
> 
> ??? I don't see a problem. Resolution works as it does now for subprograms, 
> and either there is a unique resolution or not. No one says "what would be 
> of function renaming if overloading is allowed" -- it just is and everything 
> is fine.

I thought about overloading exceptions with exceptions. Presently
exceptions are perceived as a kind of literals rather than objects. It is
untrue, but that is the desired semantics of [OK, some wanted C++ alike
semantics but that is another story]. Renaming conflicts with this.
Overloading may further erode the model.

> The primary reason for allowing overloading of exceptions (as with objects) 
> is so that they don't get hidden by something unrelated. (Especially a 
> problem for use clauses.) If you have something like (assume these 
> declarations have real names and the packages contain dozens of declarations 
> each):
> 
>    package P is
>        Error : Boolean;
>    end P;
>    package Q is
>        Error : exception;
>    end Q;
> 
>    with P, Q; use P, Q;
>    procedure R is
>    begin
>        if Error then -- (1)
>           raise Error; -- (2)
>       end if;
>    end R;
> 
> both (1) and (2) are illegal today. But there's no good reason for that;

Yes. It does not make sense.

> A thought just popped into my head, perhaps you are worrying about:
>     Name_Error : exception renames IO_Exceptions.Name_Error;
> This is thought by many to be a long time bug in Ada. If you have "use 
> Text_IO, IO_Exceptions;" then "raise Name_Error;" is illegal -- but that's 
> silly because both possibilities are the same entity.

Yes.
 
> That could be fixed by adopting a rule such that if the only reason that a 
> name is ambiguious is because it resolved to several different views of the 
> same entity, that it would be treated as properly resolved to the entity.

Right. But also that renaming were not allowed to create any objects. That
would break a lot of exiting code, but this code is already broken, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:6iqu3i2wgq5t$.166jyq7d1w1nc.dlg@40tude.net...
> On Tue, 22 Jul 2014 17:07:55 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:cso9nzjs6q5q$.16o96j9yv70q1$.dlg@40tude.net...
>>> On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote:
...
>> A thought just popped into my head, perhaps you are worrying about:
>>     Name_Error : exception renames IO_Exceptions.Name_Error;
>> This is thought by many to be a long time bug in Ada. If you have "use
>> Text_IO, IO_Exceptions;" then "raise Name_Error;" is illegal -- but 
>> that's
>> silly because both possibilities are the same entity.
>
> Yes.
>
>> That could be fixed by adopting a rule such that if the only reason that 
>> a
>> name is ambiguious is because it resolved to several different views of 
>> the
>> same entity, that it would be treated as properly resolved to the entity.
>
> Right. But also that renaming were not allowed to create any objects. That
> would break a lot of exiting code, but this code is already broken, IMO.

Renaming in Ada only creates a new view, it can't create an object. You can 
in some cases rename a temporary, but that temporary object was created by 
something else, not be the renames. So I don't think anything need be 
changed here, and thus no code would be broken.

The tough part would be writing the rule so that it worked both for 
use-visibility and for direct visibility. But it's doable, I think.

                          Randy.

Re: Functions vs constants

[G.B.]

On 23.07.14 00:07, Randy Brukardt wrote:
>     with P, Q; use P, Q;
>     procedure R is
>     begin
>         if Error then -- (1)
>            raise Error; -- (2)
>        end if;
>     end R;
>
> both (1) and (2) are illegal today. But there's no good reason for that; the
> profiles (imagining an extended idea of profile to include objects and
> exceptions) are different and there can be no more confusion between them
> than between overloaded enumeration literals.

Well, this text gives the reader a lucid hint at what the homonyms
might mean! Sounds like more context dependency as we have some
already, don't we. Good grief.

This over-overloading, rightfully frowned upon by SPARK (and not just
by SPARK), I think, plays into the hands of those programmers who like
to write less, be secretive, and brag about some unproductive linguistic
cleverness. Why force inference on readers of Ada programs?
The result is so similar to obfuscated source text. Javascript
compilers employ this very technique, i.e. they re-use names like `a'
as often as lexical bindings will permit.

IMHO, no single name should denote different objects appearing
in one piece of "discourse" (block). Prefixes are good!

JOE    - “Hey Jack!”
JACK_1 - “Yes?”
JACK_2 - “Yes?”
JOE    - “Push that jack over here!”
JACK_1 - “What?”
JACK_2 - “What has he done?"
JOE    - “No, the jack on wheels.”
JACK_1 - “None of us has wheel shoes.”
JACK_2 - “No, he means the flag.”
...

As you can see, homonyms make things appear silly (on at least
two accounts). But it doesn't stop here, since the internet of
things will, I'm certain, make jacks capable of reacting to
voice commands...

Re: Functions vs constants

[Randy Brukardt]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:lqoab0$bnm$1@dont-email.me...
> On 23.07.14 00:07, Randy Brukardt wrote:
>>     with P, Q; use P, Q;
>>     procedure R is
>>     begin
>>         if Error then -- (1)
>>            raise Error; -- (2)
>>        end if;
>>     end R;
>>
>> both (1) and (2) are illegal today. But there's no good reason for that; 
>> the
>> profiles (imagining an extended idea of profile to include objects and
>> exceptions) are different and there can be no more confusion between them
>> than between overloaded enumeration literals.
>
> Well, this text gives the reader a lucid hint at what the homonyms
> might mean! Sounds like more context dependency as we have some
> already, don't we. Good grief.

I think you miss the point. This isn't something that one intentionally 
writes (and "Error" is a terrible name just used for an example). But if one 
intends to reuse code, the client has no control over the naming of the 
entities in the reused code. Moreover (and more important), the client 
shouldn't break due to unrelated maintenance on some third-party code. 
Especially if that third-party code decides to add something with the same 
name as something that you are already using. How could they know to avoid 
it?

We had massive amounts of this problem with Claw. Almost anything one could 
do to the library would break break some possible use of the library. The 
less this is the case, the better, because it's surely not possible to 
encase libraries in amber (never changing them). And people using outdated 
versions of things is a severe problem for a software developer; it makes 
support difficult to impossible.

One could imagine a rule "no use clauses of any kind, anywhere", but that's 
not really practical (especially as it means no infix operator usage). In 
the absence of that, you're going to be at risk for problems. Moreover, even 
if "prefixes are good", they also make code unreadable (particularly if you 
have lots of child packages).

Ada has many rules that are intended to prevent Beaujolais and Ripple 
effects (cases where adding or deleting an unrelated declaration changes a 
legal program into a legal program with a different meaning). The best of 
these rules is overloading, because it doesn't make previously legal 
programs illegal because of some unrelated change. All of the other rules 
are a maintenance hazard, because they make legal programs illegal just 
because someone added something you don't care about.

Finally, a lot of what you say boils down to "overloading is bad". In that 
case, you shouldn't be using Ada at all, since it heavily depends on 
overloading (all the way back to Ada 83). To avoid overloading ("homonyms"), 
then you have to avoid "+" and Put and Read and Image and lots of other 
things.

It would only be practical to avoid overloading if all of your Ada code was 
constructed by your team, with no outside code ever involved. Then you could 
control the names used in the code. But that's not practical for any but the 
smallest projects.

> This over-overloading, rightfully frowned upon by SPARK ...

SPARK avoids overloading because the original authors of the tools didn't 
have enough knowledge of how to implement it. They then explained that as a 
"benefit", but the only benefit is that it simplified their tools. SPARK is 
a terrible example to use for programming language design, because the 
primary design criteria was what they knew how to implement. They left out a 
lot of stuff that is perfectly safe for their purposes, which really 
emasculates the language for no good reason at all. (They claim to have 
reasons, but those appear to be to have been constructed after the fact. 
It's easy to do, we did it a lot during the early subset days of 
Janus/Ada -- it's easy to spin nearly any limitation as a feature.)

                                   Randy.

Re: Functions vs constants

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3040 bytes --]

On Wed, 23 Jul 2014, Randy Brukardt wrote:

> I think you miss the point. This isn't something that one intentionally
> writes (and "Error" is a terrible name just used for an example). But if one
> intends to reuse code, the client has no control over the naming of the
> entities in the reused code. Moreover (and more important), the client
> shouldn't break due to unrelated maintenance on some third-party code.
> Especially if that third-party code decides to add something with the same
> name as something that you are already using. How could they know to avoid
> it?

It would be nice if Ada had a selective "use" clause, a bit like MODULA2's 
import:

   from Ada.Text_IO use Put, New_Line;

Now the programmer could write Put("Hello"); New_Line; but would have to 
resort to prefix notation for Ada.Text_IO.Put_Line("Hello").

This would keep your namespace free from any new identifiers the 
maintainer of Ada.Text_IO can add to the package. (Yes, Ada.Text_IO isn't 
the best example for this issue ...)

> One could imagine a rule "no use clauses of any kind, anywhere", but that's
> not really practical (especially as it means no infix operator usage).

What about allowing "use type <id>" and "use all type <id>", but 
not "use <id>"?

> In
> the absence of that, you're going to be at risk for problems. Moreover, even
> if "prefixes are good", they also make code unreadable (particularly if you
> have lots of child packages).

What about using rename?

   package PFS renames My_Project.Abstract_IO.Persistent_File_Storage;

> SPARK avoids overloading because the original authors of the tools didn't
> have enough knowledge of how to implement it.

Claiming them not to "have enough knowledge" is unfair!

SPARK has originally been written for Pascal, which doesn't support 
overloading (or didn't at that time). So the designed their tools such 
that they did heavily depend on subprogram's unique names. E.g., the 
information the toolset did generate for a subprogram was stored in a file 
with the subprogram's name.

When they changed to Ada, they didn't start from scratch, but used the 
back-end they had originally written for Pascal. Adaption to beyond-Pascal 
properties of Ada clearly had a low priority for them.

You could see that even in the output: When a hypothesis (i.e, a 
precondition) required two entities to be different, the SPARK toolset's 
output would use the Pascal symbol for not equal, rather than Ada'S "/=".

While changing the output symbol would not have been a big issue, adapting 
to overloading clearly would imply a huge amount of work, with things 
breaking all over the toolset.

> They then explained that as a
> "benefit", but the only benefit is that it simplified their tools.

Agreed!


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Functions vs constants

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.11.1407240850160.24422@debian...
On Wed, 23 Jul 2014, Randy Brukardt wrote:

...
>> SPARK avoids overloading because the original authors of the tools didn't
>> have enough knowledge of how to implement it.
>
>Claiming them not to "have enough knowledge" is unfair!

I didn't mean it quite the way it sounds, I should have tried harder to find 
exactly the right words. It simply was too hard for a tool that primarily 
does text-level analysis. Indeed, I can't imagine that they could have 
reasonably implemented Ada visibility rules (short of basing their tools on 
ASIS or some specific Ada compiler) -- it's just too hard of a project. I'm 
sure doing that wasn't a priority for them, the priority would have been the 
proof facilities.

                                 Randy.

Re: Functions vs constants

[Shark8]

On 24-Jul-14 22:43, Randy Brukardt wrote:
> It simply was too hard for a tool that primarily
> does text-level analysis. Indeed, I can't imagine that they could have
> reasonably implemented Ada visibility rules (short of basing their tools on
> ASIS or some specific Ada compiler) -- it's just too hard of a project. I'm
> sure doing that wasn't a priority for them, the priority would have been the
> proof facilities.


Programs shouldn't be analyzed as text, too many "Why can't I parse XML 
with RegEx!?" posts on programming-help sites [like StackOverflow] point 
to this.

and isn't this what DIANA was intended for: to provide access to the 
actual structure of the program [essentially] independent of the text?

Re: Functions vs constants

[Georg Bauhaus]

On 24/07/14 00:12, Randy Brukardt wrote:
> "G.B." <bauhaus@futureapps.invalid> wrote in message
> news:lqoab0$bnm$1@dont-email.me...
>> On 23.07.14 00:07, Randy Brukardt wrote:
>>>      with P, Q; use P, Q;
>>>      procedure R is
>>>      begin
>>>          if Error then -- (1)
>>>             raise Error; -- (2)
>>>         end if;
>>>      end R;
>>>
>>> both (1) and (2) are illegal today. But there's no good reason for that;
>>> the
>>> profiles (imagining an extended idea of profile to include objects and
>>> exceptions) are different and there can be no more confusion between them
>>> than between overloaded enumeration literals.
>>
>> Well, this text gives the reader a lucid hint at what the homonyms
>> might mean! Sounds like more context dependency as we have some
>> already, don't we. Good grief.
>
> I think you miss the point. This isn't something that one intentionally
> writes (and "Error" is a terrible name just used for an example). But if one
> intends to reuse code, the client has no control over the naming of the
> entities in the reused code. Moreover (and more important), the client
> shouldn't break due to unrelated maintenance on some third-party code.

I disagree, because the client should perhaps be diagnosed broken, for
reasons of maintainability of references. The latter word is meant
in the generals sense: if it takes a name resolution program to know
the named objects (again in the general sense of the word), then the
program's project management could be steering in a direction of more
helpful naming rather than in that of more complex compiler technology.

That is, if it's broken, fix it. If it needs overloading, take care.
Do not rely on ever more capable, ever more sophisticated overload
resolution technology in this case. IOW, find it suspicious if your
compiler vendor praises a somewhat complicated techno feature that
makes your bundle of homonyms still work!  ;-) ;-) ;-)


> Especially if that third-party code decides to add something with the same
> name as something that you are already using. How could they know to avoid
> it?

Neither can I. (Example below.)

> One could imagine a rule "no use clauses of any kind, anywhere", but that's
> not really practical (especially as it means no infix operator usage). In
> the absence of that, you're going to be at risk for problems. Moreover, even
> if "prefixes are good", they also make code unreadable (particularly if you
> have lots of child packages).

I agree that some kind of abbreviation mechanism is necessary. But not
through overloading, if possible. I'd rather have more errors appearing
(sic), since they can be fixed, rather than having them swept under the
rug, which is what extensive overloading will do. (Hence the example of
Javascript obfuscation; while technically correct, the result is
not maintainable.) That's on the premiss, of course, that a reader of
an ideal Ada program will know the object that some given name denotes
without doing too much resolution himself.

> Ada has many rules that are intended to prevent Beaujolais and Ripple
> effects.

Yes, and I'd like to adduce the rules that make an inner P
hide an outer P, with no "use" in sight. The client might have
to manipulate visibility of names in this case, too.

package P is
    Q : array (Natural range 8 .. 15) of Boolean;
end P;

with P;  -- added, "incompetent programmer" wonders about effect
procedure Client
is
    package P is  --  suppose "competent reviewer" had skipped
                  --  this nested inner P on first reading ...
       function Q (N : Natural) return Boolean;
    end P;

    package body P is separate;

begin
    if P.Q (12) then   --  ... and now both assume things.
       null;
    end if;
end Client;

Writing "with P;" on top of Client doesn't change this program
a bit, provided that P's elaboration has no effects. But it does
change all sorts of assumptions.  Adding more overloading could
not possibly remove the effects of more assumptions?

The same argument applies to with-ing packages from two or more
different libraries, I think. While it might seem tempting to have
a "smart" compiler resolve all naming issues through some kind
of "smart" overloading, I'm reluctant to call that a solution.

It might help getting a particular job done, but since I'm constantly
in a position of having to deal with the results in the long run,
I cannot like it that much.

> To avoid overloading ("homonyms"),
> then you have to avoid "+" and Put and Read and Image and lots of other
> things.

I think that homonyms like "+" and "Put" could be put on the "overriding"
side of "overriding vs overloading", couldn't they? (If we are allowed
to think in terms of a suitably changed language, one that reinterprets
Ada text without changing the effect of code generated for a + b.)

>> This over-overloading, rightfully frowned upon by SPARK ...
>
> SPARK avoids overloading because the original authors of the tools didn't
> have enough knowledge of how to implement it. (...)

[I have turned this political argument---about what is not---around, in the
paragraph about compiler writers who like to sell more overloading. 8-) ]

Re: Functions vs constants

[Dmitry A. Kazakov]

On Thu, 24 Jul 2014 10:27:10 +0200, Georg Bauhaus wrote:

> I think that homonyms like "+" and "Put" could be put on the "overriding"
> side of "overriding vs overloading", couldn't they?

1. Not without MI and MD, obviously. E.g. all types defining "+" would be
descendants of Additive_Group interface.

2. Not if type cloning is allowed (type X is new Y). Let you clone Integer:

   type My_Type is new Integer;

that also clones Additive_Group (all parents of My_Type down to the root).
And thus "+" gets overloaded again.

3. Generics. OK, we want to get rid of them anyway...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[G.B.]

On 24.07.14 12:11, Dmitry A. Kazakov wrote:
>> I think that homonyms like "+" and "Put" could be put on the "overriding"
>> >side of "overriding vs overloading", couldn't they?

> 1. Not without MI and MD, obviously. E.g. all types defining "+" would be
> descendants of Additive_Group interface.

Considering frequent additions,

a) won't the sum typically be produced from arguments
    of the same specific additive group, and

b) won't the result be added to more of the same specific
    type or else be subject to type conversion?

Re: Functions vs constants

[Dmitry A. Kazakov]

On Thu, 24 Jul 2014 12:49:30 +0200, G.B. wrote:

> On 24.07.14 12:11, Dmitry A. Kazakov wrote:
>>> I think that homonyms like "+" and "Put" could be put on the "overriding"
>>> >side of "overriding vs overloading", couldn't they?
> 
>> 1. Not without MI and MD, obviously. E.g. all types defining "+" would be
>> descendants of Additive_Group interface.
> 
> Considering frequent additions,
> 
> a) won't the sum typically be produced from arguments
>     of the same specific additive group, and

Sometimes yes, if you mean whether addition is covariant. But not always,
e.g. matrix addition when dimension is a part of the type.

> b) won't the result be added to more of the same specific
>     type or else be subject to type conversion?

An implicit conversion, e.g. to a sub/supertype?

-----------------
But I don't see how these details resolve the issue. If you want to get rid
of overloading, you must bring all arguments of the operation under one
roof. Since arguments may be from different type hierarchies, e.g.

   Put (File, Value)

you need MD to glue the hierarchy of files (rendering contexts) with the
hierarchy of printable entities in Put.

MI is needed because the hierarchies are not trees. You need glue additive
(+) and multiplicative groups (*) in some types (Integer), but not in all
types (Vector).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message 
news:lqqg0v$8t6$1@dont-email.me...
> On 24/07/14 00:12, Randy Brukardt wrote:
>> "G.B." <bauhaus@futureapps.invalid> wrote in message
>> news:lqoab0$bnm$1@dont-email.me...
>>> On 23.07.14 00:07, Randy Brukardt wrote:
>>>>      with P, Q; use P, Q;
>>>>      procedure R is
>>>>      begin
>>>>          if Error then -- (1)
>>>>             raise Error; -- (2)
>>>>         end if;
>>>>      end R;
>>>>
>>>> both (1) and (2) are illegal today. But there's no good reason for 
>>>> that;
>>>> the
>>>> profiles (imagining an extended idea of profile to include objects and
>>>> exceptions) are different and there can be no more confusion between 
>>>> them
>>>> than between overloaded enumeration literals.
>>>
>>> Well, this text gives the reader a lucid hint at what the homonyms
>>> might mean! Sounds like more context dependency as we have some
>>> already, don't we. Good grief.
>>
>> I think you miss the point. This isn't something that one intentionally
>> writes (and "Error" is a terrible name just used for an example). But if 
>> one
>> intends to reuse code, the client has no control over the naming of the
>> entities in the reused code. Moreover (and more important), the client
>> shouldn't break due to unrelated maintenance on some third-party code.
>
> I disagree, because the client should perhaps be diagnosed broken, for
> reasons of maintainability of references.

Sorry, but that's not the real world. If I add something to Claw that breaks 
most existing clients, I'm going to get a bunch of annoyed (or worse) 
messages from customers. People are not interested in spending a lot of time 
"fixing" code that's previously worked and does not use any of the new 
stuff.

The result is that without overloading, I can't add *anything* to Claw (or 
any existing library - including the ones in the Standard). Which means that 
everything new gets split out into new packages, and quite quickly 
everything becomes unusable. Tucker likes to say that new features should 
never look "bolted-on" -- when someone new comes to a language (or library), 
the "seams" between newer and older features shouldn't show.

...
...
> IOW, find it suspicious if your
> compiler vendor praises a somewhat complicated techno feature that
> makes your bundle of homonyms still work!  ;-) ;-) ;-)

"Your compiler vendor" (or in this case, someone else's compiler vendor :-) 
would rather do without any overloading at all. It's a pain the neck, quite 
honestly.

But as a user of Ada, and especially as someone that wants to write AND FIX 
reusuable code, it's a godsend.

...
>> To avoid overloading ("homonyms"),
>> then you have to avoid "+" and Put and Read and Image and lots of other
>> things.
>
> I think that homonyms like "+" and "Put" could be put on the "overriding"
> side of "overriding vs overloading", couldn't they? (If we are allowed
> to think in terms of a suitably changed language, one that reinterprets
> Ada text without changing the effect of code generated for a + b.)

That doesn't make any sense. "+" and especially Put work on a number of 
types that are currently completely unrelated. In what sense is Put for a 
String overriding Put for a Float? Dmitry covered this ground pretty well in 
his response.

                                                Randy.

Re: Functions vs constants

[Georg Bauhaus]

On 25/07/14 06:56, Randy Brukardt wrote:

>> I disagree, because the client should perhaps be diagnosed broken, for
>> reasons of maintainability of references.
>
> Sorry, but that's not the real world. If I add something to Claw that breaks
> most existing clients, I'm going to get a bunch of annoyed (or worse)
> messages from customers. People are not interested in spending a lot of time
> "fixing" code that's previously worked and does not use any of the new
> stuff.

All right, the sledge hammer (fixing, not adding more duct tape) is typically
part of only bigger managerial changes. OTOH, new languages Hack, Swift and
Scala will be examples of how money or size can invalidate all such arguments.
They all preserve concepts, run-time, and thus knowledge, though.

> In what sense is Put for a
> String overriding Put for a Float? Dmitry covered this ground pretty well in
> his response.

His answer includes, actually, that for Put you need non-Ada only
if the file argument should be included in dispatching. Any Float
or String arguments could be passed to an overridden version of Put
determined statically.

Re: Functions vs constants

[G.B.]

On 25.07.14 08:45, Georg Bauhaus wrote:
> Any Float
> or String arguments could be passed to an overridden version of Put
> determined statically.

Oh. Not really, since there likely is digits'Class... .-/

Re: Functions vs constants

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message 
news:lqsueh$q0v$1@dont-email.me...
> On 25/07/14 06:56, Randy Brukardt wrote:
...
>> In what sense is Put for a
>> String overriding Put for a Float? Dmitry covered this ground pretty well 
>> in
>> his response.
>
> His answer includes, actually, that for Put you need non-Ada only
> if the file argument should be included in dispatching. Any Float
> or String arguments could be passed to an overridden version of Put
> determined statically.

Huh? "overriding" only works for related types. In what universe are Float 
and String related? They have almost no common operations. "overloading" 
(which you don't want to use) works for any types, including unrelated ones.

                             Randy.

Re: Functions vs constants

[Dmitry A. Kazakov]

On Fri, 25 Jul 2014 14:31:06 -0500, Randy Brukardt wrote:

> "Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message 
> news:lqsueh$q0v$1@dont-email.me...
>> On 25/07/14 06:56, Randy Brukardt wrote:
> ...
>>> In what sense is Put for a
>>> String overriding Put for a Float? Dmitry covered this ground pretty well 
>>> in his response.
>>
>> His answer includes, actually, that for Put you need non-Ada only
>> if the file argument should be included in dispatching. Any Float
>> or String arguments could be passed to an overridden version of Put
>> determined statically.
> 
> Huh? "overriding" only works for related types. In what universe are Float 
> and String related? They have almost no common operations. "overloading" 
> (which you don't want to use) works for any types, including unrelated ones.

One thing missing in Ada is ad-hoc supertypes. That is when you could
create a common parent for existing types.

E.g. Ada.Text_IO would create an interface Printable and then pronounce it
a supertype of Integer, Float, String etc. After that Put will become a
primitive operation of Printable and thus overridden rather than
overloaded.

This is also the way of having containers of Float and String without
having a premeditated common parent type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Shark8]

On 25-Jul-14 14:02, Dmitry A. Kazakov wrote:
> One thing missing in Ada is ad-hoc supertypes. That is when you could
> create a common parent for existing types.


I can't see any way that ad-hoc supertypes won't create a huge mess.
This is fundamentally different from creating an actual super-type and 
restructuring to take advantage of it.

Re: Functions vs constants

[Dmitry A. Kazakov]

On Fri, 25 Jul 2014 20:45:38 -0600, Shark8 wrote:

> On 25-Jul-14 14:02, Dmitry A. Kazakov wrote:
>> One thing missing in Ada is ad-hoc supertypes. That is when you could
>> create a common parent for existing types.
> 
> I can't see any way that ad-hoc supertypes won't create a huge mess.
> This is fundamentally different from creating an actual super-type and 
> restructuring to take advantage of it.

The mess is to think one could design types as hierarchies. That does not
work and is unmaintainable because changes at the roots of hierarchies have
huge impact, bigger when closer to the root. This basically is the main
reason why no design could really evolve. All of them break under changes
sooner rather than later. The idea is to add hierarchies at the client's
side without changing the core functionality of involved types and without
designing heaps of meaningless helper types and adapters.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Shark8]

On 26-Jul-14 02:02, Dmitry A. Kazakov wrote:
> The mess is to think one could design types as hierarchies.

Ridiculous; it's obvious that some types really do belong in a 
hierarchy. (Granted, not the *same* hierarchy with "one root to rule 
them all, and in the darkness bind them".) -- e.g. there really should 
be a common ["generic"] root, an "abstract type" if you will, for 
strings which conceptually are "instantiated" with the different 
versions of Character (ie [[Wide_]Wide_]Character) but present to the 
programmer a single, unified interface.  The same can be said of float- 
and fixed-point numbers, and possibly integers with a root 
"universal_numeric". (The way we use "untyped constants" [named numbers] 
indicates that exact assumed interface.)

Re: Functions vs constants

[Dmitry A. Kazakov]

On Sat, 26 Jul 2014 08:03:12 -0600, Shark8 wrote:

> On 26-Jul-14 02:02, Dmitry A. Kazakov wrote:
>> The mess is to think one could design types as hierarchies.
> 
> Ridiculous; it's obvious that some types really do belong in a 
> hierarchy. (Granted, not the *same* hierarchy with "one root to rule 
> them all, and in the darkness bind them".) -- e.g. there really should 
> be a common ["generic"] root, an "abstract type" if you will, for 
> strings which conceptually are "instantiated" with the different 
> versions of Character (ie [[Wide_]Wide_]Character) but present to the 
> programmer a single, unified interface.

The point is that nobody can foresee *all* hierarchies a type participates
or may participate. These relationships are *not* global. The example was
given: the hierarchy Printable.

Type relationships are not objective for many reasons, the most important
is that it is a model of problem spaces and thus is never adequate. The
language type system should allow you adjust things instead of breaking
them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Victor Porton]

Victor Porton wrote:

> Isn't the following a mis-design of Ada?
> 
> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.
> 
> However, in Ada functions can be overloaded by their return type, while
> constants cannot.
> 
> Mad idea, but I propose it: Make in a future specification of Ada
> constants overloadable (moreover, make constants argument-less functions).
> (However I am not sure how this could affect reliability. But should we
> think about it at all? After all function overloading was not ruled out
> with the same requirements, and ruling this out as possibly unreliable
> would be a half- measure.)
> 
> I wrote this post after a practical problem whether I should use a String
> constant or a function returning String to return the library version
> (related with a C library for which I am writing bindings). There are no
> definite answer to this question. It is in any case of wrong design.

And this would be useful for writing (reliable) programs in practice:

PI: constant Float := ...;
PI: constant Long_Float := ...;

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Maciej Sobczak]

On Monday, July 21, 2014 11:18:30 PM UTC+2, Victor Porton wrote:

> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.

Why? With what definition of "good"? This is like starting with arbitrary (and subjective) assumptions.

I think that the source of such discussion is in how we perceive the role of a programming language. You can start with the machine and abstract it upwards - in this approach you might realize that there are things like registers and memory cells and a concept of variable (or constant) seems like a valid abstraction of these physical things. In this view there is no reason whatsoever to converge the notions of objects and subprograms, as these represent different physical mechanisms and this representation is well understood.
On the other hand, you can start with the concept of function as a mathematical foundation for everything else and then try to find ways to implement it on a physical machine. Starting with this idea you might end up with functions and constants (and variables) as special cases of the same thing.

Which one is correct? Both, but they represent different engineering cultures. I see Ada rather in the first category and I don't see any reason to force it into the other one. That is, please don't turn Ada into yet another functional language, there are enough of them already and getting lost in the crowd is certainly not what Ada needs today.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Functions vs constants

[Dmitry A. Kazakov]

On Tue, 22 Jul 2014 00:06:13 -0700 (PDT), Maciej Sobczak wrote:

> I think that the source of such discussion is in how we perceive the role
> of a programming language. You can start with the machine and abstract it
> upwards - in this approach you might realize that there are things like
> registers and memory cells and a concept of variable (or constant) seems
> like a valid abstraction of these physical things. In this view there is
> no reason whatsoever to converge the notions of objects and subprograms,
> as these represent different physical mechanisms and this representation
> is well understood.
> On the other hand, you can start with the concept of function as a
> mathematical foundation for everything else and then try to find ways to
> implement it on a physical machine. Starting with this idea you might end
> up with functions and constants (and variables) as special cases of the
> same thing.
> 
> Which one is correct? Both, but they represent different engineering
> cultures. I see Ada rather in the first category and I don't see any
> reason to force it into the other one.

No. The former is called "systems programming." The latter is 2application
programming." Ada is for both, being universal programming language = for
most problem spaces.

> That is, please don't turn Ada into
> yet another functional language, there are enough of them already and
> getting lost in the crowd is certainly not what Ada needs today.

I don't think this is related to functional programming, which is
essentially an attempt to abstract away any computational states. However,
indeed the only difference between a value and a parameterless function is
one of being given vs. computed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Functions vs constants

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:18igilt89njaa.n3uy7bzna7nx.dlg@40tude.net...
> On Tue, 22 Jul 2014 00:06:13 -0700 (PDT), Maciej Sobczak wrote:
...
>> That is, please don't turn Ada into
>> yet another functional language, there are enough of them already and
>> getting lost in the crowd is certainly not what Ada needs today.
>
> I don't think this is related to functional programming, which is
> essentially an attempt to abstract away any computational states.

Right.

> However, indeed the only difference between a value and a parameterless
> function is one of being given vs. computed.

Even that's muddled in Ada, since enumeration literals are parameterless 
functions with a given value. They're definitely not constants, and they're 
definitely not computed. (Expression functions muddle it a bit as well.)

That's why it would have been best to have no such distinctions at all (at 
least from a usage standpoint).

One could even imagine a radical solution of having no constants at all, as 
parameterless expression functions would serve the purpose just as well. 
(Too radical, I think, as the syntax of an expression function would be too 
verbose for the use.)

                                   Randy.

Re: Functions vs constants

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> One could even imagine a radical solution of having no constants at all, as 
> parameterless expression functions would serve the purpose just as well. 
> (Too radical, I think, as the syntax of an expression function would be too 
> verbose for the use.)

What would happen if we changed the definition of a constant declaration
to be syntax sugar for the equivalant parameterless expression function?

-- 
-- Stephe

Re: Functions vs constants

[Victor Porton]

Stephen Leake wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> One could even imagine a radical solution of having no constants at all,
>> as parameterless expression functions would serve the purpose just as
>> well. (Too radical, I think, as the syntax of an expression function
>> would be too verbose for the use.)
> 
> What would happen if we changed the definition of a constant declaration
> to be syntax sugar for the equivalant parameterless expression function?

I think it is not enough. We need also specify that it is a static value.

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Adam Beneschan]

On Wednesday, July 23, 2014 6:21:34 AM UTC-7, Stephen Leake wrote:
> "Randy Brukardt" writes:
> 
> > One could even imagine a radical solution of having no constants at all, as 
> > parameterless expression functions would serve the purpose just as well. 
> > (Too radical, I think, as the syntax of an expression function would be too 
> > verbose for the use.)
> 
> What would happen if we changed the definition of a constant declaration
> to be syntax sugar for the equivalant parameterless expression function?

Constants behave like objects.  If you have a constant of a controlled type, it has to be Finalized like a variable object.  If you say "X : constant Access_To_Something := new Something'(blahblahblah)", then how would this work if it's syntactic sugar for a function--would it allocate a new Something every time it's accessed?  

                                -- Adam

Re: Functions vs constants

[Robert A Duff]

Victor Porton <porton@narod.ru> writes:

> Isn't the following a mis-design of Ada?
>
> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.

Those are equivalent in a pure functional language.  Not in Ada.

E.g. a constant initialized to "new T" always denotes the same heap
object, whereas a function that says "return new T" returns a new
object every time it's called.

> However, in Ada functions can be overloaded by their return type, while 
> constants cannot.

I agree.  IMHO everything should be overloadable.  For consistency,
among other things.  Confusion should be minimized, not by disallowing
overloading of certain kinds of declarations, but by making the
resolution rules "not too smart".  That is, anything that is likely to
confuse a programmer should be ambiguous, and therefore illegal, by the
resolution rules.

It really is odd that this allows overloading:

    type Color is (Red, Orange, Yellow);

but this does not:

    type Color is range ...;
    Red: constant Color := 0;
    Orange: constant Color := 1;
    Yellow: constant Color := 2;

And there should be no hiding.  Jean Ichbiah had a brilliant idea about
how use clauses should work (for overloadable declarations).  He should
have applied that to all visibility, not just use visibility.

> Mad idea, but I propose it: Make in a future specification of Ada constants 
> overloadable...

A good idea in 1980, but it can't happen now.  For one thing, it's hard
to see how to do that without breaking compatibility, as I think Randy
pointed out.  For another, it's just not badly broken enough to bother
fixing at this point.

And expression functions make this restriction somewhat less painful.

>... (moreover, make constants argument-less functions).

I don't see any reason to tie "is a subprogram" to "is overloadable".
That's done for enumeration literals, but it's just plain weird, IMHO.

- Bob

Re: Functions vs constants

[Victor Porton]

Robert A Duff wrote:

> Victor Porton <porton@narod.ru> writes:
> 
>> Isn't the following a mis-design of Ada?
>>
>> Constants in a good programming language should be equivalent to
>> argument- less functions which return these constants.
> 
> Those are equivalent in a pure functional language.  Not in Ada.
> 
> E.g. a constant initialized to "new T" always denotes the same heap
> object, whereas a function that says "return new T" returns a new
> object every time it's called.

You've misunderstood me.

I don't say that every function should be equivalent to a constant, but just 
that every constant should be equivalent to a function.

A function that says "return new T" is not equivalent to a constant.

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Robert A Duff]

Victor Porton <porton@narod.ru> writes:

> You've misunderstood me.
>
> I don't say that every function should be equivalent to a constant, but just 
> that every constant should be equivalent to a function.
>
> A function that says "return new T" is not equivalent to a constant.

I don't understand.  What function is equivalent to this constant?

    X: constant A := new T;

- Bob

Re: Functions vs constants

[Victor Porton]

Robert A Duff wrote:

> Victor Porton <porton@narod.ru> writes:
> 
>> You've misunderstood me.
>>
>> I don't say that every function should be equivalent to a constant, but
>> just that every constant should be equivalent to a function.
>>
>> A function that says "return new T" is not equivalent to a constant.
> 
> I don't understand.  What function is equivalent to this constant?
> 
>     X: constant A := new T;

The following function is equivalent to this constant:

function F return A is
begin
   return X;
end;

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Pascal Obry]

Le mercredi 23 juillet 2014 à 17:57 -0400, Robert A Duff a écrit : 
> Those are equivalent in a pure functional language.  Not in Ada.
> 
> E.g. a constant initialized to "new T" always denotes the same heap
> object, whereas a function that says "return new T" returns a new
> object every time it's called.

So let's introduce the Once attribute from Eiffel language to solve
that :) In Eiffel a Once function does whatever it is supposed to do the
first time then it *always* returns the same result for subsequent
calls. This then looks like a complex constant.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Functions vs constants

[anon]

It the definition "Constants" From RM 3.3 (13).

"The value of a constant object cannot be changed between its 
initialization and its finalization," while overloading might 
lead to ambiguity which violate Ada rules. At the same Constants 
are more likey to be static while only a set number of functions 
type can every be static, RM 4.9 ( 18 => ( 19 .. 22 ) ).


Now, function overloading just allow one to use the same name 
with different aspect to resolute which actual function routine 
to use. But for some constant object there is no aspect to 
allow overloading to resolute the actual value.

An example:

                                          -- Base Type

    type Limited_Integer is range .. ;    -- Limited_Integer

    Five : constant := 5 ;                -- universal integer
    Five : constant Short_Integer := 2 ;  -- Short_Integer
    Five : constant Float := 8.0 ;        -- Float
    Five : constant := 3.33 ;             -- universal float

    
    --  Ambiguous expressions:

    --    which is the current value the universal integer ( 5 )
    --    or the Short_Integer ( 2 )

    X    : Limited_Integer := Limited_Integer ( Five ) ;

    --    This should choose the universal integer but the type
    --    and value may be hidden because of overloading.

    Y    : Limited_Integer := Five ;

even though the base type is different in each constant object
the use does not allow the system to fully choose which value 
should be used in the variable statements.

And if the constant objects are defined in different packages the 
compiler normally hides the visibility of all package. To 
limit the ambiguous expressions.


So, how would you define an overloading constant objects that would not
lead to an ambiguous expressions?




In <lqk032$9h$1@speranza.aioe.org>, Victor Porton <porton@narod.ru> writes:
>Isn't the following a mis-design of Ada?
>
>Constants in a good programming language should be equivalent to argument-
>less functions which return these constants.
>
>However, in Ada functions can be overloaded by their return type, while 
>constants cannot.
>
>Mad idea, but I propose it: Make in a future specification of Ada constants 
>overloadable (moreover, make constants argument-less functions). (However I 
>am not sure how this could affect reliability. But should we think about it 
>at all? After all function overloading was not ruled out with the same 
>requirements, and ruling this out as possibly unreliable would be a half-
>measure.)
>
>I wrote this post after a practical problem whether I should use a String 
>constant or a function returning String to return the library version 
>(related with a C library for which I am writing bindings). There are no 
>definite answer to this question. It is in any case of wrong design.
>
>-- 
>Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Victor Porton]

Victor Porton wrote:

> Isn't the following a mis-design of Ada?
> 
> Constants in a good programming language should be equivalent to argument-
> less functions which return these constants.
> 
> However, in Ada functions can be overloaded by their return type, while
> constants cannot.
> 
> Mad idea, but I propose it: Make in a future specification of Ada
> constants overloadable (moreover, make constants argument-less functions).
> (However I am not sure how this could affect reliability. But should we
> think about it at all? After all function overloading was not ruled out
> with the same requirements, and ruling this out as possibly unreliable
> would be a half- measure.)
> 
> I wrote this post after a practical problem whether I should use a String
> constant or a function returning String to return the library version
> (related with a C library for which I am writing bindings). There are no
> definite answer to this question. It is in any case of wrong design.

It seems to me, that making constants functions (and so overloadable) would 
not change meaning of any legal Ada program.

Thus, in my opinion, there is no reason to refuse this my proposal to make 
constants functions (and so overloadable).

-- 
Victor Porton - http://portonvictor.org

Re: Functions vs constants

[Robert A Duff]

Victor Porton <porton@narod.ru> writes:

> It seems to me, that making constants functions (and so overloadable) would 
> not change meaning of any legal Ada program.

I think you can construct cases that are currently legal that would
become illegal with your proposed change.  How about this:

   procedure Overloaded(X: Integer);
   procedure Overloaded(X: Boolean);

   procedure P is
      X: constant Integer := 1;

      procedure Q is
         X: constant Boolean := True;
      begin
         Overloaded(X);
         ...

The above is legal, and calls the Boolean version of Overloaded.
If the X's overloaded each other, it would be ambiguous, and
therefore illegal.

Now, you might say the above SHOULD be illegal, and I'd agree.
But it's currently legal, and we shouldn't be breaking legal
programs.

> Thus, in my opinion, there is no reason to refuse this my proposal to make 
> constants functions (and so overloadable).

Another reason is implementation difficulty.  I suspect it might be
an earthquake for some implementations, so it might not be worth
the trouble -- not sufficiently broken.

- Bob

Re: Functions vs constants

[Adam Beneschan]

On Thursday, July 24, 2014 9:01:43 AM UTC-7, Robert A Duff wrote:

>    procedure P is 
>       X: constant Integer := 1;
> 
>       procedure Q is
>          X: constant Boolean := True;
>       begin
>          Overloaded(X);
>          ...

> Now, you might say the above SHOULD be illegal, and I'd agree.
> But it's currently legal, and we shouldn't be breaking legal
> programs.

If the "X: Integer" constant is used only in the body of P, it can be moved down below Q, just above P's "begin".  But it should be noted that this was not possible in Ada 83, where there was less freedom about how things in a declarative part were ordered.  So it wouldn't surprise me if there is legacy Ada 83 code that does something like your example, i.e. declaring the same constant name in a scope and a nested scope, such that both would become visible if constant declarations were made overloadable.

                            -- Adam

Re: Functions vs constants

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccegxa9254.fsf@shell01.TheWorld.com...
...
>   procedure Overloaded(X: Integer);
>   procedure Overloaded(X: Boolean);
>
>   procedure P is
>      X: constant Integer := 1;
>
>      procedure Q is
>         X: constant Boolean := True;
>      begin
>         Overloaded(X);
>         ...
>
> The above is legal, and calls the Boolean version of Overloaded.
> If the X's overloaded each other, it would be ambiguous, and
> therefore illegal.

This could be fixed with a complicated enough rule. Probably not worth it, 
but possible (I proposed such in the integrated package delibrations).

But I recall that such overloading also could cause an inconsistency (a case 
where a legal program would do something different after the overloading was 
introduced). That cannot be tolerated, and I don't think that there was any 
rule that eliminated that short of not allowing overloading. (I'm not going 
to try to look up that example since we're definitely not doing this, so I 
fear this could appear to be FUD.)

                                     Randy.