some trivial questions?

some trivial questions?

[tclwarrior]

Why in ada, there is a separation between functions and procedures?
Is there any real value in this? 

Also why does is Use imply With? 
For example why do i have to say:

with Ada.Text_IO;
use Ada.Text_IO;


Is there any case where the Use statement will be ambiguous, if i skip the with part?

Thanks
Ali

Re: some trivial questions?

[Shark8]

On Wednesday, November 1, 2017 at 12:44:20 PM UTC-6, tclwa...@gmail.com wrote:
> Why in ada, there is a separation between functions and procedures?
> Is there any real value in this?

Yes, there's a *LOT* of value here; the easiest way to illustrate this in conjunction with Private Types. Consider the following:

  Package Example is
    
    -- Handle is a monotonically increasing value, for the run of the program.
    Type Handle is private;
    
    Function Create Return Handle;
    Function Value( Object : Handle ) Return Positive;
    
  Private
    Type Handle is new Positive;
  End Example;

Everything that you really need to know about using the types and functions are given in the specification above. Below we have the actual implementation.


  Package Body Example is
    Count : Natural := 0;
    
    Function Create Return Handle is
    Begin
      Count:= Natural'Succ( Count );
      Return Handle( Count );
    End Create;
    
    Function Value( Object : Handle ) Return Positive is
      ( Positive(Object) );
    
  End Example;

> 
> Also why does is Use imply With? 

Because they are really about two different things:
WITH is really about dependency.
USE is about [direct] visibility.

> For example why do i have to say:
> 
> with Ada.Text_IO;
> use Ada.Text_IO;

Because "with Ada.Text_IO" is simply saying that you're depending on the "Text_IO" compilation-unit inside-or-subordinate-to the compilation-unit "Ada".

The "use Ada.Text_IO" is about importing the whole namespace "Ada.Text_IO" into the current visibility scope.

> Is there any case where the Use statement will be ambiguous, if i skip the with part?

You cannot skip the with part.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-01 19:44, tclwarrior@gmail.com wrote:

> Why in ada, there is a separation between functions and procedures?

Function considered free of side-effects, even on the arguments, though 
the latter was changed recently. Procedures are more general case 
subprograms.

Apart from functions and procedures Ada has entries of task and 
protected object. Entry is a procedure with a queue where the caller can 
wait for the entry become ready ("open" in Ada terms) to be called.

> Is there any real value in this?

Function can return an indefinite object. Procedure and entry cannot.

> Also why does is Use imply With?

Alas, it does not.

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

Re: some trivial questions?

[Luke A. Guest]

<tclwarrior@gmail.com> wrote:
> Why in ada, there is a separation between functions and procedures?
> Is there any real value in this? 

In maths a function returns something, well it maps one set onto another,
but you get the idea. A procedure is a bunch of steps that don't return a
value.

Other languages do this too, just not the C ones.

Re: some trivial questions?

[Robert A Duff]

Luke A. Guest <laguest@archeia.com> writes:

> In maths a function returns something, well it maps one set onto another,
> but you get the idea. A procedure is a bunch of steps that don't return a
> value.

Well, yes, but Ada isn't maths.  An Ada function can have side effects.
And if it has no side effects, it describes a bunch of steps that
compute a maths function.  It seems wrong to say that an Ada function
that computes the maths factorial function IS that maths function.
The Ada function is a "procedure" or "method" (one of many) for
computing that maths function.

- Bob

Re: some trivial questions?

[Jeffrey R. Carter]

On 11/01/2017 07:44 PM, tclwarrior@gmail.com wrote:
> Why in ada, there is a separation between functions and procedures?
> Is there any real value in this?

There are 2 kinds of languages: those in which all subprograms are called the 
same thing, even though some return a value and some don't

and

Those in which subprograms that return a value have a different name from those 
that don't.

Ada is in the 2nd group.

The 1st group seems to be further divided into 2 groups: those in which all 
subprograms are called functions, and those in which they're all called procedures.

> Also why does is Use imply With?

Use does not imply With.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: some trivial questions?

[tclwarrior]

> with Ada.Text_IO;
> use Ada.Text_IO;
> 

i made a typo in my original post, which i think may have caused some confusion 

i meant to say, why doesn't "use" imply "with" 
i think every time you insert  
a use, you will most definitely add a with

it just look to me, that this is a bit redundant to add two line, when one should do ... the compiler can should easily assume that 

use Ada.Text_IO
Also means with Ada.Text_IO .. 
and to borrow some Shark8 words

if i am telling the compiler 
import (use) Ada.Text_IO ... i surely also mean, that i depend (with) on Ada.Text_IO

i think in a program with a large import (use) list of libraries, this can 
save many lines and looks cleaner

Re: some trivial questions?

[Luke A. Guest]

<tclwarrior@gmail.com> wrote:
>> with Ada.Text_IO;
>> use Ada.Text_IO;
>> 
> 
> i made a typo in my original post, which i think may have caused some confusion 
> 
> i meant to say, why doesn't "use" imply "with" 
> i think every time you insert  
> a use, you will most definitely add a with

You don't always. It adds to readability to use package names as well in
function calls for example. 

> 
> it just look to me, that this is a bit redundant to add two line, when
> one should do ... the compiler can should easily assume that 

Some companies insist on not using use in code, you can use renaming, I do.

Luke

Re: some trivial questions?

[gautier_niouzes]

> i meant to say, why doesn't "use" imply "with"

The "use" can be in any declarative place in the code. Sometimes it is practical to have it locally, for instance if you are using both Text_IO and Stream_IO but not at the same places.
You can also "use" a package you just defined a few lines above, or a nested package. In this case there is no library-level package to "with".
If "use" implied "with", there would be sometimes more ambiguities to sort out (on "use A, B", B could then mean a library-level package called B, or A.B (a child or a nested package of A). Ouch!

That being said, I find a "with then use" clause would be useful.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: some trivial questions?

[Robert A Duff]

gautier_niouzes@hotmail.com writes:

> If "use" implied "with", there would be sometimes more ambiguities to
> sort out (on "use A, B", B could then mean a library-level package
> called B, or A.B (a child or a nested package of A). Ouch!

No, that's not how "use A, B;" works.  The things in A and B
become potentially use-visible after the use clause, so the
B cannot be something made use-visible by the "use A".

So it's not equivalent to "use A; use B;".

> That being said, I find a "with then use" clause would be useful.

Yes, it would!  But the "with then" is just noise.
Plain "use" (in a context clause, which is the only place
where a "with" clause is allowed) would be more readable.

- Bob

Re: some trivial questions?

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wccvainc94w.fsf@TheWorld.com...
> gautier_niouzes@hotmail.com writes:
>
>> If "use" implied "with", there would be sometimes more ambiguities to
>> sort out (on "use A, B", B could then mean a library-level package
>> called B, or A.B (a child or a nested package of A). Ouch!
>
> No, that's not how "use A, B;" works.  The things in A and B
> become potentially use-visible after the use clause, so the
> B cannot be something made use-visible by the "use A".
>
> So it's not equivalent to "use A; use B;".
>
>> That being said, I find a "with then use" clause would be useful.
>
> Yes, it would!  But the "with then" is just noise.
> Plain "use" (in a context clause, which is the only place
> where a "with" clause is allowed) would be more readable.

Banning package use everywhere would be more maintainable. ;-)

Seriously, the less one uses "use" on packages (as opposed to types), the 
better. I'd be strongly opposed to anything that made it easier to "use" 
use; it's going to the wrong way. If you really need visibility, use "use 
type".

                                       Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 02/11/2017 02:19, tclwarrior@gmail.com wrote:

> i think every time you insert a use, you will most definitely add a 
> with> it just look to me, that this is a bit redundant to add two
> line, when one should do ... the compiler can should easily assume
> that
Yes. There is no reason why "with" could not be deduced from "use". E.g. 
it is no problem to move with out of the local scope:

    declare
       use Bar; -- Cannot have with Bar here, but who cares?
    begin
       ...

There is no problem to determine if "use" refers to a local package like:

    declare
       package Foo is new Boo;
       use Foo; -- Cannot with Foo, but again who cares?
    begin

It is historically so and also there is a great unjustified sentiment 
against "use" in Ada community. I have a theory that people are either 
lazy to design their package in a way to make it friendly for "use" or 
take too big dosages of generics (:-)). Ada generics are totally "use" 
unfriendly.

> i think in a program with a large import (use) list of libraries, this can
> save many lines and looks cleaner

This is rather a different issue. "Use" is not transitive. If you "use 
A" in B and then "use B" in C that does not make "use A" in C. In a 
great number of cases one would like to have transitive "use". In many 
other cases one would like to have it as it is. This is a long-standing 
problem of having to reusable "package interfaces".

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

Re: some trivial questions?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> It is historically so and also there is a great unjustified sentiment
> against "use" in Ada community.

Have you ever tried to work out how GNAT does something from its
internals? (I don't mean the libraries, but the compiler itself).

AdaCore used to use the rename-package-as-abbreviation pattern a lot,

   package SSE renames System.Storage_Elements;

which helped a little once you got used to the standard abbreviations.

I did in fact work out that you can write a post-facto GPR to help
explore the compiler's internals: e.g.

   project Gcc_8 is

      for Source_Dirs use ("gcc-8-20170528-build/gcc/ada",
                           "gcc-8-20170528/gcc/ada");
      for Object_Dir use "gcc-8-20170528-build/gcc/ada";
      for Languages use ("Ada", "C");

   end Gcc_8;

(I'm not 100% sure this would work as-is with the latest structure,
because the compiler itself uses the RTS, and the RTS sources are now in
gcc/ada/lib{gnat,gnarl}).

Re: some trivial questions?

[Dmitry A. Kazakov]

On 02/11/2017 14:21, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> It is historically so and also there is a great unjustified sentiment
>> against "use" in Ada community.
> 
> Have you ever tried to work out how GNAT does something from its
> internals? (I don't mean the libraries, but the compiler itself).
> 
> AdaCore used to use the rename-package-as-abbreviation pattern a lot,
> 
>     package SSE renames System.Storage_Elements;
> 
> which helped a little once you got used to the standard abbreviations.

That is the most annoying thing. People do not like "use" yet are not 
ready to face the consequences of their ideological choice. So they do a 
thing which combines disadvantages of both approaches.

> I did in fact work out that you can write a post-facto GPR to help
> explore the compiler's internals: e.g.
> 
>     project Gcc_8 is
> 
>        for Source_Dirs use ("gcc-8-20170528-build/gcc/ada",
>                             "gcc-8-20170528/gcc/ada");
>        for Object_Dir use "gcc-8-20170528-build/gcc/ada";
>        for Languages use ("Ada", "C");
> 
>     end Gcc_8;

That is cool.

I usually declare a thing from the package which name AdaCore had 
scrambled and then use GPS' go-to-declaration to open the package.

P.S. GPS could have quick search in the project pane and have all Ada 
RTS packages there.

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

Re: some trivial questions?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 02/11/2017 14:21, Simon Wright wrote:
>> AdaCore used to use the rename-package-as-abbreviation pattern a lot,

Used to?  That style is used in the run-time system,
but not so much in the compiler.

>>     package SSE renames System.Storage_Elements;
>>
>> which helped a little once you got used to the standard abbreviations.
>
> That is the most annoying thing. People do not like "use" yet are not
> ready to face the consequences of their ideological choice. So they do a
> thing which combines disadvantages of both approaches.

I agree.  Using an unhelpful name like SSE (as in SSE.Storage_Array)
does not add useful information, but does add noise.  Either
Storage_Array or System.Storage_Elements.Storage_Array is better.

And how do you make sure that every package uses the same abbreviations
for other packages?

- Bob

Re: some trivial questions?

[Simon Wright]

Robert A Duff <bobduff@TheWorld.com> writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On 02/11/2017 14:21, Simon Wright wrote:
>>> AdaCore used to use the rename-package-as-abbreviation pattern a lot,
>
> Used to?  That style is used in the run-time system,
> but not so much in the compiler.

Yes, there seem to be only 6 instances in the compiler (all of children
of GNAT.Spitbol).

And one at least looks silly -- ceinfo.adb,

   package TV renames GNAT.Spitbol.Table_VString;
   use TV;

Instead, the compiler goes over the top (IMO) with 'use' - par.adb,

   with Aspects;  use Aspects;
   with Atree;    use Atree;
   with Casing;   use Casing;
   with Debug;    use Debug;
   with Elists;   use Elists;
   with Errout;   use Errout;
   with Fname;    use Fname;
   with Lib;      use Lib;
   with Namet;    use Namet;
   with Namet.Sp; use Namet.Sp;
   with Nlists;   use Nlists;
   with Nmake;    use Nmake;
   with Opt;      use Opt;
   with Output;   use Output;
   with Par_SCO;  use Par_SCO;
   with Restrict; use Restrict;
   with Scans;    use Scans;
   with Scn;      use Scn;
   with Sem_Util; use Sem_Util;
   with Sinput;   use Sinput;
   with Sinput.L; use Sinput.L;
   with Sinfo;    use Sinfo;
   with Snames;   use Snames;
   with Style;
   with Stylesw;  use Stylesw;
   with Table;
   with Tbuild;   use Tbuild;

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oteku0$ek3$1@gioia.aioe.org...
> On 02/11/2017 02:19, tclwarrior@gmail.com wrote:
>> i think every time you insert a use, you will most definitely add a with> 
>> it just look to me, that this is a bit redundant to add two
>> line, when one should do ... the compiler can should easily assume
>> that
> Yes. There is no reason why "with" could not be deduced from "use".

True, but many Ada users find it valuable to have a list of dependencies at 
the top of each unit. The list of explicit "with"s provides this. When we 
were working on what eventually became "limited with", several good ideas 
were rejected (more by the Ada community than the ARG) because the 
dependency was not listed at the top of the unit.

As far as "use" clauses code, package use clauses are always a maintenance 
hazard as they make non-overloadable things visible. I suggest avoiding them 
as much as possible on that basis. "use type" and "use all type" avoid that 
problem and thus are much less likely to cause maintenance problems in the 
future. (And prefix notation, which avoids the need for any sort of "use" 
completely, is even better.)

                                       Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 17/11/2017 01:51, Randy Brukardt wrote:

> True, but many Ada users find it valuable to have a list of dependencies at
> the top of each unit.

Heavy background of C's includes, maybe? (:-)) I learned C after Ada, I 
hate includes.

> As far as "use" clauses code, package use clauses are always a maintenance
> hazard as they make non-overloadable things visible.

Which would be good as it allowed earlier detection of errors. However 
the argument is obviously bogus because any name change is a maintenance 
problem regardless the length of that name.

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

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oum6qv$1bdr$1@gioia.aioe.org...
> On 17/11/2017 01:51, Randy Brukardt wrote:
...
>> As far as "use" clauses code, package use clauses are always a 
>> maintenance
>> hazard as they make non-overloadable things visible.
>
> Which would be good as it allowed earlier detection of errors. However the 
> argument is obviously bogus because any name change is a maintenance 
> problem regardless the length of that name.

Changing names of overloadable things is not a maintenance hazard unless the 
things have the exact same profile. (And that's a problem by any definition, 
having two identical entities with different meanings.)

An alternative fix for this problem would be to make more things (preferably 
all things) overloadable. But that would cause some existing Ada code to 
silently change meaning, which is considered unacceptable. (It also would 
require some sort of meta-types, which I'd rather not try to get into, but 
that's a detail.) So it's not going to happen for Ada.

Use type clauses (and prefix notation) don't have these maintenance problems 
(they only operate on overloadable entities), so I think they should be 
preferred to package use.

                            Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-18 02:14, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:oum6qv$1bdr$1@gioia.aioe.org...
>> On 17/11/2017 01:51, Randy Brukardt wrote:
> ...
>>> As far as "use" clauses code, package use clauses are always a
>>> maintenance hazard as they make non-overloadable things visible.
>>
>> Which would be good as it allowed earlier detection of errors. However the
>> argument is obviously bogus because any name change is a maintenance
>> problem regardless the length of that name.
> 
> Changing names of overloadable things is not a maintenance hazard unless the
> things have the exact same profile. (And that's a problem by any definition,
> having two identical entities with different meanings.)

And if they are not overloadable I still can use long names. Use-clause 
makes nothing worse than already is.

> An alternative fix for this problem would be to make more things (preferably
> all things) overloadable. But that would cause some existing Ada code to
> silently change meaning, which is considered unacceptable. (It also would
> require some sort of meta-types, which I'd rather not try to get into, but
> that's a detail.) So it's not going to happen for Ada.

Sure, nothing useful going to happen for Ada. But speaking of 
alternatives, another one is to make illegal use-clauses that cause hiding.

> Use type clauses (and prefix notation) don't have these maintenance problems
> (they only operate on overloadable entities), so I think they should be
> preferred to package use.

Use type is an ugly hack.

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

Re: some trivial questions?

[J-P. Rosen]

Le 18/11/2017 à 10:19, Dmitry A. Kazakov a écrit :
> Sure, nothing useful going to happen for Ada. But speaking of
> alternatives, another one is to make illegal use-clauses that cause hiding.
No use clause can cause hiding, except for mutual hiding which is a good
thing: if a name is potentially ambiguous, the user has to tell which
one is intended.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: some trivial questions?

[Dmitry A. Kazakov]

On 20/11/2017 06:40, J-P. Rosen wrote:
> Le 18/11/2017 à 10:19, Dmitry A. Kazakov a écrit :
>> Sure, nothing useful going to happen for Ada. But speaking of
>> alternatives, another one is to make illegal use-clauses that cause hiding.
> No use clause can cause hiding, except for mutual hiding which is a good
> thing: if a name is potentially ambiguous, the user has to tell which
> one is intended.

This is what I meant. If hiding occurs the program would be illegal 
unless the user provides a renaming for each conflicting name.

This must be the rule for all similar cases too. Each name space must be 
forcibly kept consistent.

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

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ouotuh$1ig3$1@gioia.aioe.org...
> On 2017-11-18 02:14, Randy Brukardt wrote:
...
>> Changing names of overloadable things is not a maintenance hazard unless 
>> the
>> things have the exact same profile. (And that's a problem by any 
>> definition,
>> having two identical entities with different meanings.)
>
> And if they are not overloadable I still can use long names. Use-clause 
> makes nothing worse than already is.

Giving things junk names to avoid name conflicts is more evil than even 
package use clauses. ;-) See the bogus naming conventions of C systems where 
encoded type names are jammed into other things. That makes it all the 
harder to model the problem space (rather than the solution space).

>> An alternative fix for this problem would be to make more things 
>> (preferably
>> all things) overloadable. But that would cause some existing Ada code to
>> silently change meaning, which is considered unacceptable. (It also would
>> require some sort of meta-types, which I'd rather not try to get into, 
>> but
>> that's a detail.) So it's not going to happen for Ada.
>
> Sure, nothing useful going to happen for Ada.

I agree that this is annoying. The problem is that an incompatible Ada would 
be starting over from scratch (as existing libraries would not be usable), 
and whether such a thing could get traction (and get new versions of GTK and 
Claw and Dmitry's libraries, and so on.) is unknown. If it didn't get 
traction, it would be of little practical interest - and a lot of work.

                                                 Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-20 23:03, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ouotuh$1ig3$1@gioia.aioe.org...
>> On 2017-11-18 02:14, Randy Brukardt wrote:
> ...
>>> Changing names of overloadable things is not a maintenance hazard unless
>>> the
>>> things have the exact same profile. (And that's a problem by any
>>> definition,
>>> having two identical entities with different meanings.)
>>
>> And if they are not overloadable I still can use long names. Use-clause
>> makes nothing worse than already is.
> 
> Giving things junk names to avoid name conflicts is more evil than even
> package use clauses. ;-)

Sure, remove one of the use-clauses then. The point is that either there 
must be no conflicts or else all of them must be explicitly resolved. It 
is more like manifested vs. implicit approach.

> See the bogus naming conventions of C systems where encoded type
> names are jammed into other things. That makes it all the harder to
> model the problem space (rather than the solution space).
I think it is more related to C's weak typing and thus lack of 
overloading than to a single name space.

>> Sure, nothing useful going to happen for Ada.
> 
> I agree that this is annoying. The problem is that an incompatible Ada would
> be starting over from scratch (as existing libraries would not be usable),

There are lots of changes which can be made while keeping everything 
compatibility. The problem is with small increments. That does not work. 
If we want to do something real this must be done in one large jump. 
This worked for Ada 95 once, it can work again.

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

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ov0v0f$663$1@gioia.aioe.org...
> On 2017-11-20 23:03, Randy Brukardt wrote:
...
>>> Sure, nothing useful going to happen for Ada.
>>
>> I agree that this is annoying. The problem is that an incompatible Ada 
>> would
>> be starting over from scratch (as existing libraries would not be 
>> usable),
>
> There are lots of changes which can be made while keeping everything 
> compatibility. The problem is with small increments. That does not work. 
> If we want to do something real this must be done in one large jump. This 
> worked for Ada 95 once, it can work again.

The problem with this sort of thing is *proving* that the changes are in 
fact compatible. In the absence of that, the forces of FUD would have a 
field day, and it would be very hard to convince people that there was no 
problem.

That has plagued every Ada update since Ada 95. (Did you know that Ada 95 
was supposed to have a mechanism where operators were always visible? That 
got killed off in favor of "use type" in part because the Ada 9x team 
couldn't convince the MRT that there wasn't any possible incompatibility.)

Similar issues have occurred for every version of Ada since. (Attempts to 
fix the problem of tagged derived types in generic units among others have 
died because of compatibility concerns. Similarly, my attempt to allow 
untagged type declarations in the private part of protected types seems to 
have died for that reason, even though it's not possible for there to be an 
incompatibility [I think]. I think there is a currently open AI that 
probably will be eventually dropped because of compatibility concerns, 
rather than making it into Ada 2020. And so it goes...)

Of course, a true proof is hard to do when the rules are primarily modeled 
in English as opposed to some formal system. So this is a very hard problem 
twice over.

                                   Randy.

Re: some trivial questions?

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Of course, a true proof is hard to do when the rules are primarily modeled 
> in English as opposed to some formal system.

I'm surprised Ada doesn't have a formal semantics.  Maybe that's
something that should be fixed?

Re: some trivial questions?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87mv3fdsi3.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Of course, a true proof is hard to do when the rules are primarily 
>> modeled
>> in English as opposed to some formal system.
>
> I'm surprised Ada doesn't have a formal semantics.  Maybe that's
> something that should be fixed?

That was attempted during Ada 9x, but the problem was that there was no way 
for normal humans to see if the formal semantics in fact properly modeled 
the language. Only the authors actually understood the formal model.

Creating a model that both formal and understandable by a run-of-the-mill 
language lawyer and finding volunteers to create the model seems unlikely 
(to say the least).

                                            Randy.

Re: some trivial questions?

[Victor Porton]

Randy Brukardt wrote:

> "Paul Rubin" <no.email@nospam.invalid> wrote in message
> news:87mv3fdsi3.fsf@nightsong.com...
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>> Of course, a true proof is hard to do when the rules are primarily
>>> modeled
>>> in English as opposed to some formal system.
>>
>> I'm surprised Ada doesn't have a formal semantics.  Maybe that's
>> something that should be fixed?
> 
> That was attempted during Ada 9x, but the problem was that there was no

Attempted in 90th?!

Which formal proof assistant was used?

> way for normal humans to see if the formal semantics in fact properly
> modeled the language. Only the authors actually understood the formal
> model.
> 
> Creating a model that both formal and understandable by a run-of-the-mill
> language lawyer and finding volunteers to create the model seems unlikely
> (to say the least).
> 
>                                             Randy.
-- 
Victor Porton - http://portonvictor.org

Re: some trivial questions?

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Creating a model that both formal and understandable by a run-of-the-mill 
> language lawyer and finding volunteers to create the model seems unlikely 
> (to say the least).

Well I thought Ada was originally sponsored by big-money defense
agencies, but maybe that was only Ada-83.  Anyway, I do think there was
some formalization work for Scheme in the 1980s and ML in the 1990s.  I
can understand how it could be much harder for Ada, since Scheme and ML
operate under some convenient illusions like having infinite memory,
which Ada cannot.

Re: some trivial questions?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87efoper6i.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Creating a model that both formal and understandable by a run-of-the-mill
>> language lawyer and finding volunteers to create the model seems unlikely
>> (to say the least).
>
> Well I thought Ada was originally sponsored by big-money defense
> agencies, but maybe that was only Ada-83.

Ada 9x (which ultimately became Ada 95) was also a big-money project. But 
all work since has been accomplished basically by volunteers; I'm the only 
paid person, and only for about 1/4 time. (Volunteers don't do the 
paper-pushing jobs that are necessary to finish a project, especially in the 
world of international standards, thus some paid person is necessary, 
certainly for projects that are long-lasting like Ada.)

> Anyway, I do think there was
> some formalization work for Scheme in the 1980s and ML in the 1990s.  I
> can understand how it could be much harder for Ada, since Scheme and ML
> operate under some convenient illusions like having infinite memory,
> which Ada cannot.

There was some formalization work for Ada as part of the Ada 9x project 
(remember, "big money" as you described it). I don't know much about it 
other than that it existed; perhaps Tucker Taft or Bob Duff (both of whom 
worked at the center of the Ada 9x project) know more.

                                 Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 22/11/2017 01:56, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ov0v0f$663$1@gioia.aioe.org...
>> On 2017-11-20 23:03, Randy Brukardt wrote:
> ...
>>>> Sure, nothing useful going to happen for Ada.
>>>
>>> I agree that this is annoying. The problem is that an incompatible Ada
>>> would
>>> be starting over from scratch (as existing libraries would not be
>>> usable),
>>
>> There are lots of changes which can be made while keeping everything
>> compatibility. The problem is with small increments. That does not work.
>> If we want to do something real this must be done in one large jump. This
>> worked for Ada 95 once, it can work again.
> 
> The problem with this sort of thing is *proving* that the changes are in
> fact compatible. In the absence of that, the forces of FUD would have a
> field day, and it would be very hard to convince people that there was no
> problem.

The idea which is floating around for a long while is to introduce a 
more general type system in which present standard would be expressed 
as-is without any changes. Compatibility problems arise when doing 
incremental changes at the same abstraction level, Once you move up or 
down there is no problem anymore.

> That has plagued every Ada update since Ada 95. (Did you know that Ada 95
> was supposed to have a mechanism where operators were always visible? That
> got killed off in favor of "use type" in part because the Ada 9x team
> couldn't convince the MRT that there wasn't any possible incompatibility.)

That is exactly the solution like above but at a narrower scale - you 
can have operators either visible or not. The method was actually not to 
decide that and simply implement both variants. The first variant was 
made default the second received the syntax "use type".

At a larger scale the problem is that the language may fall apart if we 
keep on adding arbitrary syntax constructs like "use type". This is why 
it must be one major change.

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

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ov3dah$rb$1@gioia.aioe.org...
> On 22/11/2017 01:56, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:ov0v0f$663$1@gioia.aioe.org...
>>> On 2017-11-20 23:03, Randy Brukardt wrote:
>> ...
>>>>> Sure, nothing useful going to happen for Ada.
>>>>
>>>> I agree that this is annoying. The problem is that an incompatible Ada
>>>> would
>>>> be starting over from scratch (as existing libraries would not be
>>>> usable),
>>>
>>> There are lots of changes which can be made while keeping everything
>>> compatibility. The problem is with small increments. That does not work.
>>> If we want to do something real this must be done in one large jump. 
>>> This
>>> worked for Ada 95 once, it can work again.
>>
>> The problem with this sort of thing is *proving* that the changes are in
>> fact compatible. In the absence of that, the forces of FUD would have a
>> field day, and it would be very hard to convince people that there was no
>> problem.
>
> The idea which is floating around for a long while is to introduce a more 
> general type system in which present standard would be expressed as-is 
> without any changes. Compatibility problems arise when doing incremental 
> changes at the same abstraction level, Once you move up or down there is 
> no problem anymore.
>
>> That has plagued every Ada update since Ada 95. (Did you know that Ada 95
>> was supposed to have a mechanism where operators were always visible? 
>> That
>> got killed off in favor of "use type" in part because the Ada 9x team
>> couldn't convince the MRT that there wasn't any possible 
>> incompatibility.)
>
> That is exactly the solution like above but at a narrower scale - you can 
> have operators either visible or not. The method was actually not to 
> decide that and simply implement both variants. The first variant was made 
> default the second received the syntax "use type".
>
> At a larger scale the problem is that the language may fall apart if we 
> keep on adding arbitrary syntax constructs like "use type". This is why it 
> must be one major change.

I agree with your points, but how do you prove compatibility of whatever 
model is adopted? Given that Ada is currently defined with English wording, 
it is very hard to prove if any change is compatible other than the most 
trivial ones. When you change a lot of that English text (as would be 
necessary if a new underlying abstraction was adopted), how do you convince 
skeptics that the results are the same (or at least very close to the same)? 
That's been the problem for any radical changes in the type system or in 
resolution.

                                         Randy.

Re: some trivial questions?

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I agree with your points, but how do you prove compatibility of whatever 
> model is adopted? Given that Ada is currently defined with English wording, 

Is that really a big problem?  I know Ada shops like Praxis have been
writing specifications in Z-notation for ages, while being able to get
customers understanding what the specs mean.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 23/11/2017 01:19, Randy Brukardt wrote:

> I agree with your points, but how do you prove compatibility of whatever
> model is adopted? Given that Ada is currently defined with English wording,
> it is very hard to prove if any change is compatible other than the most
> trivial ones.

Is it really necessary? I mean it is not different from the promises 
each compiler vendors gives. We trust that Ada standard is possible to 
implement on a machine X. A more fundamental language core is kind of 
machine Y. Nothing to prove, actually.

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

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ov61c7$o80$1@gioia.aioe.org...
> On 23/11/2017 01:19, Randy Brukardt wrote:
>
>> I agree with your points, but how do you prove compatibility of whatever
>> model is adopted? Given that Ada is currently defined with English 
>> wording,
>> it is very hard to prove if any change is compatible other than the most
>> trivial ones.
>
> Is it really necessary? I mean it is not different from the promises each 
> compiler vendors gives. We trust that Ada standard is possible to 
> implement on a machine X. A more fundamental language core is kind of 
> machine Y. Nothing to prove, actually.

It's necessary to have some sort of assurance of equivalence. Otherwise the 
forces of FUD (which includes pretty much everyone at some point or other) 
will have an open field and it is unlikely anything substantial would get 
adopted. The form of that assurance probably doesn't matter as much.

For instance, if you had a trusted implementation of the existing language 
(which we can assume is true) and a trusted implementation of the revised 
language, one could compare what they do on a sufficiently large set of 
examples (the ACATS + additional source would certainly work). But the 
problem here is getting a trusted implementation of the revised rules --  
that's either a lot of work or a lot of handwaving (neither of which is 
going to engender much confidence).

There probably are other possibilities. But there's no chance of a change 
without some sort of assurance.

                                           Randy.

Re: some trivial questions?

[G. B.]

Randy Brukardt <randy@rrsoftware.com> wrote:
> how do you convince 
> skeptics that the results are the same (or at least very close to the same)? 

You create that change of business which splits 
languages into “legacy” and “lessons learned”.

Look around you.

One question to ask is, “If we drop X, then
what’s the gain?”

Re: some trivial questions?

[Blady]

Le mercredi 22 novembre 2017 01:56:29 UTC+1, Randy Brukardt a écrit :
<...>
> Similar issues have occurred for every version of Ada since. (Attempts to 
> fix the problem of tagged derived types in generic units among others have 
> died because of compatibility concerns. Similarly, my attempt to allow 
> untagged type declarations in the private part of protected types seems to 
> have died for that reason, even though it's not possible for there to be an 
> incompatibility [I think]. I think there is a currently open AI that 
> probably will be eventually dropped because of compatibility concerns, 
> rather than making it into Ada 2020. And so it goes...)
<...>
>                                    Randy.

Hello,
Avoiding compatibility issues is mostly a concern for customers of existing commercial Ada compilers.

Here is the Ada standard implementation of some commercial Ada compilers:
AdaCore: Ada 2012
PTC ObjectAda (Atego): Ada 2005
PTC ApexAda (Rational): Ada 2005
DDC International: Ada 95
Green Hills Software: Ada 95
Irvine Compiler Corporation: Ada 95 (Ada 2005 is in limited beta testing)
OC-Systems: Ada 95
RR Software: Ada 95 (selected Ada 2007 features)
XGC: Ada 95
SCORE Ada DDC-I: Ada 95
XD Ada DXC Technology: Ada 95
(Please correct if I'm wrong)
(see full list with WEB link on http://www.adalog.fr/fr/outils_payants.html)
I'm quite surprise not to find some still with Ada 83, maybe old DEC or IBM ones.

In 2017, why aren't they all at Ada 2012 standard?
One clue may be that customers which are mainly conservative (Spatial, Aeronautics, Defense... domains) are not so demanding. Remember "The demand makes the offer".
Then the evolution process is made of small compatible changes to be attractive to customers and then compiler providers.
But in majority they don't upgrade!
Thus who cares about being compatible for new standard?
So go on attractive changes, more fashionable some people says disruptive changes, with possibly compatibility issues that may fixed after.
The point is that some duration is mandatory to analyse true effects of compatibility issues and after make them residuals.
Thus when commercial compiler providers and their customers are well aware of residuals issues they can decide to upgrade (or not) for stable attractive features.
Surely idealistic point of view ;-)
Actually, it is a question of trade off, maybe the present cursor position is too conservative.
Regards Pascal.

Re: some trivial questions?

[J-P. Rosen]

Le 23/11/2017 à 20:57, Blady a écrit :
> I'm quite surprise not to find some still with Ada 83, maybe old DEC
> or IBM ones.
> 
> In 2017, why aren't they all at Ada 2012 standard? One clue may be
> that customers which are mainly conservative (Spatial, Aeronautics,
> Defense... domains) are not so demanding. Remember "The demand makes
> the offer".

I had endless discussions with people at GreenHills about that. Their
position is: "if we find some customer with big pockets who is willing
to pay for it, we'll make it"

I tried to explain that if a customer has a choice between a vendor who
says "if you pay a lot, you'll have it two years from now" and another
one who says "no problem, we have it off-the-shelf", the choice is
obvious... No avail, they don't seem to listen.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: some trivial questions?

[Shark8]

On Thursday, November 23, 2017 at 2:30:00 PM UTC-7, J-P. Rosen wrote:
> Le 23/11/2017 à 20:57, Blady a écrit :
> > I'm quite surprise not to find some still with Ada 83, maybe old DEC
> > or IBM ones.
> > 
> > In 2017, why aren't they all at Ada 2012 standard? One clue may be
> > that customers which are mainly conservative (Spatial, Aeronautics,
> > Defense... domains) are not so demanding. Remember "The demand makes
> > the offer".
> 
> I had endless discussions with people at GreenHills about that. Their
> position is: "if we find some customer with big pockets who is willing
> to pay for it, we'll make it"
> 
> I tried to explain that if a customer has a choice between a vendor who
> says "if you pay a lot, you'll have it two years from now" and another
> one who says "no problem, we have it off-the-shelf", the choice is
> obvious... No avail, they don't seem to listen.

I agree, but on the other hand I can see the logic they're going with: there's no guarantee that they'll be able to sell an Ada 2012 [or 2020] compiler, much less pay for the development thereof.

On the other other hand, though, by not having a latest-standard compliant compiler they're actually missing out on being perceived as a leader in the field -- much like someone who programs in Algol 60 [or 68] would be regarded as "behind the times" by modern-day programmers, despite the language having some interesting features (like assigning a non-compatable type as a syntax error, or the parallel processing facilities).

Re: some trivial questions?

[Dennis Lee Bieber]

On Thu, 23 Nov 2017 11:57:33 -0800 (PST), Blady <p.p11@orange.fr> declaimed
the following:


>In 2017, why aren't they all at Ada 2012 standard?
>One clue may be that customers which are mainly conservative (Spatial, Aeronautics, Defense... domains) are not so demanding. Remember "The demand makes the offer".

	And one reason for that lack of demand is that those domains tend to
require validated compilers -- and a change in compiler may also lead to
having to completely certify any software products produced by said
compiler. A mere bug fix in the product may be able to reuse prior
certification artifacts and only require recertification of the procedure
that was modified.

	Certification can take months, if not years, for products that are
expected to be in use for decades.

	I believe when my former employer moved from a genuine VAX/VMS for
development to OpenVMS running in a VAX emulation on a Windows server, they
had to validate the compiler again -- even though it was the /same binary/
build system (XD Ada 83 as I recall). They may have managed to speed this
validation by running differences on resulting binary files to show that
the compiler produced identical running code [barring embedded date
information].

>Then the evolution process is made of small compatible changes to be attractive to customers and then compiler providers.
>But in majority they don't upgrade!
>Thus who cares about being compatible for new standard?

	Heck -- in above environment, not even Ada's tasking model was
permitted, relying instead upon calling task creation via a minimal RTOS
(because the RTOS behavior was certified, but Ada tasking was considered an
unknown); nor anything that required dynamic memory allocation past the
"initialization" functions, once the application transitioned to "running"
all memory allocation is blocked.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: some trivial questions?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

"Blady" <p.p11@orange.fr> wrote in message 
news:b30a173a-fdbf-40b8-8cae-ef71f937e08c@googlegroups.com...
Le mercredi 22 novembre 2017 01:56:29 UTC+1, Randy Brukardt a écrit :
<...>
> Similar issues have occurred for every version of Ada since. (Attempts to
> fix the problem of tagged derived types in generic units among others have
> died because of compatibility concerns. Similarly, my attempt to allow
> untagged type declarations in the private part of protected types seems to
> have died for that reason, even though it's not possible for there to be 
> an
> incompatibility [I think]. I think there is a currently open AI that
> probably will be eventually dropped because of compatibility concerns,
> rather than making it into Ada 2020. And so it goes...)
...
>Here is the Ada standard implementation of some commercial Ada compilers:
>AdaCore: Ada 2012
...
>RR Software: Ada 95 (selected Ada 2007 features)

The 2017 preview also has selected Ada 2012 features [very selected: hardly 
anything got finished in the 2017 development cycle, but the groundwork for 
a lot of things was laid].

The primary reason we haven't done more is limited development resources; 
building big compiler features can take a large amount of development time. 
I suspect that is true for many of the Ada compiler companies.

                                   Randy.

Re: some trivial questions?

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

On Wed, 1 Nov 2017, tclwarrior@gmail.com wrote:

> i meant to say, why doesn't "use" imply "with" i think every time you 
> insert a use, you will most definitely add a with

Well, in short textbook examples you will find something like

   "with Ada.Text_IO; use Ada.Text_IO",

as the so-called "context clause" (the first few lines of code, with only 
"with" and "use" clauses).

But you should not extrapolate to larger programs. You may have to "with" 
plenty of packages. But if they "use" more than one or two of them
in the context clause, the readability of your program quickly declines. 
It can be quite hard to figure out to which package a certain subprogram 
you are calling belongs to.


It is often better to "use" libraries locally, rather than in context 
clauses. On the other hand, to "use" them (or to use them without a "use" 
clause), you must always "with" them in the context clause. You could say,
the "with"s in the context clause define the dependencies of your program.


Variant 1: use in context clause:

with Ada.Text_IO;
use Ada.Text_IO;

procedure Hello_World is
begin
   Put_Line("Hello World!");
end Hello_World;


Variant 2: "use" local

with Ada.Text_IO;

procedure Hello_World is
   use Ada.Text_IO;
begin
   Put_Line("Hello World!");
end Hello_World;


In thsz example, the difference between context-clause "use" and local 
"use" does not really matter. But if you have a bigger package, it greatly 
improves the readability to "use Ada.Text_IO" only in those subprograms, 
which actually perform textual IO. Same for "use"ing other packages in 
other subprograms, of course.


> i think in a program with a large import (use) list of libraries, this can
> save many lines and looks cleaner

As I worte before: You may have to "with" a long list of libraries, but 
you should never "use" more than one or two of them in the context clause.


--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: some trivial questions?

[Simon Wright]

tclwarrior@gmail.com writes:

> i think in a program with a large import (use) list of libraries, this
> can save many lines and looks cleaner

I don't have stats on this, but if a package has a large enough set of
withed packages the package itself will probably be too big for comfort.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 02/11/2017 11:29, Simon Wright wrote:
> tclwarrior@gmail.com writes:
> 
>> i think in a program with a large import (use) list of libraries, this
>> can save many lines and looks cleaner
> 
> I don't have stats on this, but if a package has a large enough set of
> withed packages the package itself will probably be too big for comfort.

"With" tend to accumulate towards the final packages of the project. It 
is difficult to fight. Although important, because GNAT has a nasty 
memory issue directly related to the number of withed packages.

BTW, would you count

    with A.B.C.D;

as 1 or 4?

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

Re: some trivial questions?

[Jeffrey R. Carter]

On 11/02/2017 02:19 AM, tclwarrior@gmail.com wrote:
> 
> i meant to say, why doesn't "use" imply "with"
> i think every time you insert
> a use, you will most definitely add a with

No. One reason they're separate is because you can "use" things that you can't 
"with".

> i think in a program with a large import (use) list of libraries, this can
> save many lines and looks cleaner

If you have long lists of use statements in your context clauses, then your code 
is unreadable so it doesn't matter.

There is a trade off between using and not using use in terms of readability. 
Judicious use of use can make code more readable, but too much use has the 
opposite effect. In pedagogic code I tend to avoid use completely. In real code 
I have no problem with use statements with fairly large scope for common and 
well known pkgs, such as Ada.Strings.Unbounded. For other pkgs I tend to prefer 
to limit use statements to fairly small scopes in which there are enough 
references to entities from the used pkg to make it worthwhile (for me, that 
tends to be about 5).

-- 
Jeff Carter
"I've seen projects fail miserably for blindly
applying the Agile catechism: we're Agile, we
don't need to stop and think, we just go ahead
and code!"
Bertrand Meyer
150

Re: some trivial questions?

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> In real code I have no problem with use statements with fairly large
> scope for common and well known pkgs, such as Ada.Strings.Unbounded.

In that specific case, the data type is named so as to be use-friendly
(Unbounded_String).

Re: some trivial questions?

[gautier_niouzes]

> Why in ada, there is a separation between functions and procedures?

With a function you typically query some information without changing anything; with a procedure you execute something, usually with a change. E.g.

   function Target_Start (Control : Editor_Type) return Position;
   procedure Target_Start (Control : in out Editor_Type; pos : Position);

> Is there any real value in this?
It is very practical to spot - especially in a large package - where are the functions and where are the procedures.

G.

Re: some trivial questions?

[joakimds]

One person who has influenced the Ada community for avoiding the usage of use-statements is John Barnes. He writes in several places of his books "There is a strong school of thought against the usage of use-statements". It influenced me for a period of totally avoidíng use-statements and instead using tagged types to be able to use the object-prefix notation and take advantage of "use type" and "use all type". There are situations today where I would use use-statements i.e. when forced to stick to the Ada95 or Ada83 standards. There may be other sitatuions as well, but I'm gonna keep this reply short and sweet.

Re: some trivial questions?

[G. B.]

<tclwarrior@gmail.com> wrote:
> Why in ada, there is a separation between functions and procedures?
> Is there any real value in this? 
> 
> Also why does is Use imply With? 
> For example why do i have to say:
> 
> with Ada.Text_IO;
> use Ada.Text_IO;
> 

Imagine you were to list the set of implicitly with-ed
units, and “use“ has been used locally (as it should 
IMHO), *and* the software configuration is broken,
so that the compiler cannot analyse the text anymore.

Then, the presence of both “with” and “use” in the
language renders putting a mention of dependences
a valuable extra.

Re: some trivial questions?

[Pascal Obry]

Le mercredi 01 novembre 2017 à 11:44 -0700, tclwarrior@gmail.com a écrit :
> Also why does is Use imply With? 
> For example why do i have to say:
> 
> with Ada.Text_IO;
> use Ada.Text_IO;

Because with is for dependencies. Imagine you'll have to look in all
the unit to check for the "use" if you want to know what are the
dependencies!

Also, it is better to put the use locally where it is really needed and
even if possible avoid uses. When the package is defined to avoid
"use", then it is no harder to not use "use" clauses.

As an example Unbounded_String has been designed to be "use". The
package is named: Ada.Strings.Unbounded_String. So Unbounded_String is
a self contained name, Ada.Strings is just noise here.

Now if the name was named just Unbounded, then you may just "use Ada"
and write:

   Strings.Unbounded

No longer, no harder, no more verbose than:

   Unbounded_String

And add some "use [all] type" where it applies to have the operator
visible.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-06 21:53, Pascal Obry wrote:

> Because with is for dependencies. Imagine you'll have to look in all
> the unit to check for the "use" if you want to know what are the
> dependencies!

Why imagine things nobody ever does? GNAT warns about redundant with- 
and use-clauses. GNAT checks elaboration order and other problems with 
dependencies.

With projects of typical size it is impossible to do these things manually.

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

Re: some trivial questions?

[Pascal Obry]

Le lundi 06 novembre 2017 à 22:07 +0100, Dmitry A. Kazakov a écrit :
> Why imagine things nobody ever does?

Why do you imagine that everybody does only what you do?

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-06 22:14, Pascal Obry wrote:
> Le lundi 06 novembre 2017 à 22:07 +0100, Dmitry A. Kazakov a écrit :
>> Why imagine things nobody ever does?
> 
> Why do you imagine that everybody does only what you do?

Because there are certain physiological and economical limits applying 
to everybody. It is practically impossible to check package dependencies 
manually, just so.

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

Re: some trivial questions?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1510002854.30535.27.camel@obry.net...
Le lundi 06 novembre 2017 à 22:07 +0100, Dmitry A. Kazakov a écrit :
>> Why imagine things nobody ever does?
>
>Why do you imagine that everybody does only what you do?

Why would you (Dmitry) imagine all Ada users use GNAT? Janus/Ada doesn't 
warn about most of those things (they're not wrong, and they don't cause any 
performance problems, either at compile-time or runtime, so why worry?)

                                           Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 17/11/2017 01:57, Randy Brukardt wrote:

> Janus/Ada doesn't
> warn about most of those things (they're not wrong, and they don't cause any
> performance problems, either at compile-time or runtime, so why worry?)

Because if you support the view that "with" makes any sense then 
with-clauses should be written consistently with that sense. If manual 
maintaining of dependencies is felt so important then the compiler 
should assist that practice unless considered wrong.

I always remove redundant clauses because they are heavy maintenance 
problem. Some stray "with" can cause elaboration order problem which may 
stay undetected till the end of build cycle which in my case takes whole 
week. It is very nasty, I has it a couple of times.

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

Re: some trivial questions?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I always remove redundant clauses because they are heavy maintenance
> problem. Some stray "with" can cause elaboration order problem which
> may stay undetected till the end of build cycle which in my case takes
> whole week. It is very nasty, I has it a couple of times.

Which is one reason GNAT warns about this.

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oum79h$1c7v$1@gioia.aioe.org...
> On 17/11/2017 01:57, Randy Brukardt wrote:
>
>> Janus/Ada doesn't
>> warn about most of those things (they're not wrong, and they don't cause 
>> any
>> performance problems, either at compile-time or runtime, so why worry?)
>
> Because if you support the view that "with" makes any sense then 
> with-clauses should be written consistently with that sense. If manual 
> maintaining of dependencies is felt so important then the compiler should 
> assist that practice unless considered wrong.
>
> I always remove redundant clauses because they are heavy maintenance 
> problem. Some stray "with" can cause elaboration order problem which may 
> stay undetected till the end of build cycle which in my case takes whole 
> week. It is very nasty, I has it a couple of times.

I didn't mean to imply that I leave junk withs around when I know about 
them. But elaboration problems only can come from withs in specifications, 
and most of the code I work on doesn't with much in each spec. (Janus/Ada 
has a handful of packages of type declarations that are withed into pretty 
much every unit, but pretty much everything else is only withed in bodies.)

But I can see how you could get elaboration problems, especially with an 
object-oriented design. (Janus/Ada predates object-oriented programming; the 
only object-oriented language that I had heard if in 1980 was Simula, and 
there was no practical implementations of that.) Our experience with 
elaboration and elaboration control in Janus/Ada was so bad that we 
essentially abandoned it for doing anything and went back to explicit 
initializer subprograms (which we could ensure got called in the correct 
order). As such, we rarely had elaboration issues.

                                            Randy.

P.S. A one week build? Yuck. I don't think we ever had anything longer than 
about 12 hours, even back on very early MS-DOS. Of course, the compiler was 
a lot smaller (and less complete) back then. Running the entire ACATS took a 
week, but you could run individual chapters in a few hours each.

Re: some trivial questions?

[Dennis Lee Bieber]

On Fri, 17 Nov 2017 19:27:20 -0600, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:


>P.S. A one week build? Yuck. I don't think we ever had anything longer than 
>about 12 hours, even back on very early MS-DOS. Of course, the compiler was 
>a lot smaller (and less complete) back then. Running the entire ACATS took a 
>week, but you could run individual chapters in a few hours each.

	And here I used to think a four hour build cycle was rather excessive
Back in 1981... (building a requirements traceability system [almost a
relational database but for the lack of dynamic "project" operation] -- on
a CDC MP-60 hardened for air-drop)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-18 02:27, Randy Brukardt wrote:

> P.S. A one week build? Yuck. I don't think we ever had anything longer than
> about 12 hours, even back on very early MS-DOS. Of course, the compiler was
> a lot smaller (and less complete) back then. Running the entire ACATS took a
> week, but you could run individual chapters in a few hours each.

10 targets + lots of generics + GNU linker that makes the trick.

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

Re: some trivial questions?

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> As an example Unbounded_String has been designed to be "use". The
> package is named: Ada.Strings.Unbounded_String. So Unbounded_String is
> a self contained name, Ada.Strings is just noise here.

(ARM A.5.4) The package is named Ada.Strings.Unbounded! and I'm afraid
that in consequence the rest of the post doesn't really make sense

> Now if the name was named just Unbounded, then you may just "use Ada"
> and write:
>
>    Strings.Unbounded
>
> No longer, no harder, no more verbose than:
>
>    Unbounded_String
>
> And add some "use [all] type" where it applies to have the operator
> visible.

Re: some trivial questions?

[Pascal Obry]

Le lundi 06 novembre 2017 à 21:16 +0000, Simon Wright a écrit :
> (ARM A.5.4) The package is named Ada.Strings.Unbounded! and I'm
> afraid that in consequence the rest of the post doesn't really make
> sense

No it even makes more sense to my point.

   Ada.Strings.Unbounded.Unbounded_String

Even more verbosity and repetition. So yes, this package has been made
to be "use". If the object was named Object for example, then:

   Var : Unbounded.Object;

or

   Var : Strings.Unbounded.Object;

Reads fine.

I usually use this pattern for my projects and avoid using "use"
clause. That's one choice.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

Re: some trivial questions?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1510004582.30535.37.camel@obry.net...
>No it even makes more sense to my point.
>
>   Ada.Strings.Unbounded.Unbounded_String

Yup, and I write the above as I don't use Unbounded_String often enough to 
"use" it. And it annoys me every time, as package use is a major maintenance 
hazard.

                                    Randy.

Re: some trivial questions?

[Robert A Duff]

tclwarrior@gmail.com writes:

> Why in ada, there is a separation between functions and procedures?

Probably because Pascal did it that way, and Ada is (very loosely!)
based on Pascal.

> Is there any real value in this? 

Not really.  I'd prefer that both things be called "procedure".
Then we wouldn't need the terms "function" and "subprogram".
But we'd still need a distinction between procedures that
return a value and those that don't.

I'd also prefer that function results and 'out' parameters
have identical semantics, which they don't in Ada.
The difference should be purely syntactic.

> Also why does is Use imply With? 

As mentioned elsewhere, you meant "why DOESN'T use imply with?".
It should.  A use_clause that occurs in a context clause,
and that mentions a library package name, should imply a "with"
on that package.  But you don't want use_clauses that are
nested deep inside some block_statement to imply a "with".
And as others have mentioned, "use" should usually (but not
always) be deeply nested.

I think nested packages and child packages should have identical
semantics (so "with" should apply to both).  That was probably
impossible, because child packages were invented too late.

And it's annoying that if you want to use a package,
you have to with it, and "with" is not a verb in English.

> For example why do i have to say:
>
> with Ada.Text_IO;
> use Ada.Text_IO;
>
> Is there any case where the Use statement will be ambiguous, if i skip
> the with part?

No, there's no semantic problem with what you suggest.

There's no readability problem either, because a use clause
in a context clause is clearly in a context clause.
Assuming, of course, that you didn't want OTHER use
clauses (deeply nested) to imply a with (up at the top).

- Bob

Re: some trivial questions?

[Dennis Lee Bieber]

On Mon, 06 Nov 2017 17:37:31 -0500, Robert A Duff <bobduff@TheWorld.com>
declaimed the following:


>Not really.  I'd prefer that both things be called "procedure".
>Then we wouldn't need the terms "function" and "subprogram".
>But we'd still need a distinction between procedures that
>return a value and those that don't.
>
	Back when I learned FORTRAN (F-IV), both were "subprograms",
differentiated as "function subprogram" and "subroutine subprogram".

	These days, I'd probably replace "subroutine" with "procedure", but
leave both as the category of "subprogram".
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: some trivial questions?

[Dmitry A. Kazakov]

On 06/11/2017 23:37, Robert A Duff wrote:
> tclwarrior@gmail.com writes:

>> Is there any real value in this?
> 
> Not really.  I'd prefer that both things be called "procedure".

Or function return null (:-))

> Then we wouldn't need the terms "function" and "subprogram".
> But we'd still need a distinction between procedures that
> return a value and those that don't.

And we still need distinction between them in protected objects. But 
that is the issue of conflation of dedicated output with no-effects.

> I'd also prefer that function results and 'out' parameters
> have identical semantics, which they don't in Ada.

Yes, but there are syntax problems with that:

    procedure Generate_Two_Strings (X, Y : out String);

How do I declare

    X, Y : constant String := Generate_Two_Strings;

How do I do

    2 x Ada.Text_IO.Put_Line (Generate_Two_Strings);

> But you don't want use_clauses that are
> nested deep inside some block_statement to imply a "with".

Why not?

BTW, there is no reason why "with" should not be nested. If a unit can 
depend or not on a unit so a block can. One could even invent some 
interesting elaboration rules for nested "with"s. (:-)) And in effect 
nested "with" do exist for separate bodies.

> I think nested packages and child packages should have identical
> semantics (so "with" should apply to both).  That was probably
> impossible, because child packages were invented too late.

Yes. E.g. what if nested package instantiation would not imply "with"? 
Should the similar [flawed] logic apply here as to "use"?

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

Re: some trivial questions?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> And we still need distinction between them in protected objects. But
> that is the issue of conflation of dedicated output with no-effects.

Making protected functions special in that way was a
mistake, I think.

>> I'd also prefer that function results and 'out' parameters
>> have identical semantics, which they don't in Ada.
>
> Yes, but there are syntax problems with that:
>
>    procedure Generate_Two_Strings (X, Y : out String);
>
> How do I declare
>
>    X, Y : constant String := Generate_Two_Strings;

Something like:

    X, Y : constant String;
    Generate_Two_Strings (X, Y);

could be made to work.  But that's nothing like Ada.

> How do I do
>
>    2 x Ada.Text_IO.Put_Line (Generate_Two_Strings);

Store them in constants, I guess.

>> But you don't want use_clauses that are
>> nested deep inside some block_statement to imply a "with".
>
> Why not?

Because the with's show the overall structure of the program,
so should be near the top of each package.  (I'd prefer inside
the package, rather than before it.)

> BTW, there is no reason why "with" should not be nested. If a unit can
> depend or not on a unit so a block can. One could even invent some
> interesting elaboration rules for nested "with"s. (:-)) And in effect
> nested "with" do exist for separate bodies.

The rules about subunits are just plain weird.  They confuse the
issues of visibility/dependence and separate compilation.

>> I think nested packages and child packages should have identical
>> semantics (so "with" should apply to both).  That was probably
>> impossible, because child packages were invented too late.
>
> Yes. E.g. what if nested package instantiation would not imply "with"?
> Should the similar [flawed] logic apply here as to "use"?

I don't understand those questions.

- Bob

Re: some trivial questions?

[Dmitry A. Kazakov]

On 08/11/2017 23:49, Robert A Duff wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I'd also prefer that function results and 'out' parameters
>>> have identical semantics, which they don't in Ada.
>>
>> Yes, but there are syntax problems with that:
>>
>>     procedure Generate_Two_Strings (X, Y : out String);
>>
>> How do I declare
>>
>>     X, Y : constant String := Generate_Two_Strings;
> 
> Something like:
> 
>      X, Y : constant String;
>      Generate_Two_Strings (X, Y);
> 
> could be made to work.  But that's nothing like Ada.

Nothing like a good language at all.

>> How do I do
>>
>>     2 x Ada.Text_IO.Put_Line (Generate_Two_Strings);
> 
> Store them in constants, I guess.

That defeats the purpose and what about objects with loaded semantics, 
like controlled helper types (references etc). It is not a good idea to 
produce named copies of in whatever form.

[ Passing arguments to subprograms is a directed graph. With only one 
child per node it is simple to write the graph down in a bracketed form. 
Without that it becomes kind of weird. ]

>> BTW, there is no reason why "with" should not be nested. If a unit can
>> depend or not on a unit so a block can. One could even invent some
>> interesting elaboration rules for nested "with"s. (:-)) And in effect
>> nested "with" do exist for separate bodies.
> 
> The rules about subunits are just plain weird.  They confuse the
> issues of visibility/dependence and separate compilation.

or maybe reflect the reality?

>>> I think nested packages and child packages should have identical
>>> semantics (so "with" should apply to both).  That was probably
>>> impossible, because child packages were invented too late.
>>
>> Yes. E.g. what if nested package instantiation would not imply "with"?
>> Should the similar [flawed] logic apply here as to "use"?
> 
> I don't understand those questions.

    package Foo is new Bar;
    use Foo; -- That must be illegal

Now the "right" way:

    package Foo is new Bar;
    with Foo; -- For the sake of "showing dependencies"
    use Foo;  -- That's right!

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

Re: some trivial questions?

[AdaMagica]

Am Donnerstag, 9. November 2017 09:49:40 UTC+1 schrieb Dmitry A. Kazakov:
> >> Yes. E.g. what if nested package instantiation would not imply "with"?
> >> Should the similar [flawed] logic apply here as to "use"?
> > 
> > I don't understand those questions.
> 
>     package Foo is new Bar;
>     use Foo; -- That must be illegal
> 
> Now the "right" way:
> 
>     package Foo is new Bar;
>     with Foo; -- For the sake of "showing dependencies"
>     use Foo;  -- That's right!

But that's weird.

declare
  package P is ... end P;
  with P;  -- You really want this? Bah!
  use P;

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-09 16:36, AdaMagica wrote:
> Am Donnerstag, 9. November 2017 09:49:40 UTC+1 schrieb Dmitry A. Kazakov:
>>>> Yes. E.g. what if nested package instantiation would not imply "with"?
>>>> Should the similar [flawed] logic apply here as to "use"?
>>>
>>> I don't understand those questions.
>>
>>      package Foo is new Bar;
>>      use Foo; -- That must be illegal
>>
>> Now the "right" way:
>>
>>      package Foo is new Bar;
>>      with Foo; -- For the sake of "showing dependencies"
>>      use Foo;  -- That's right!
> 
> But that's weird.
> 
> declare
>    package P is ... end P;
>    with P;  -- You really want this? Bah!
>    use P;

As weird as

with Ada.Text_IO;
use  Ada.Text_IO;

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

Re: some trivial questions?

[AdaMagica]

Am Donnerstag, 9. November 2017 17:58:19 UTC+1 schrieb Dmitry A. Kazakov:
> On 2017-11-09 16:36, AdaMagica wrote:
> >> Now the "right" way:
> >>
> >>      package Foo is new Bar;
> >>      with Foo; -- For the sake of "showing dependencies"
> >>      use Foo;  -- That's right!
> > 
> > But that's weird.
> > 
> > declare
> >    package P is ... end P;
> >    with P;  -- You really want this? Bah!
> >    use P;
> 
> As weird as
> 
> with Ada.Text_IO;
> use  Ada.Text_IO;

At library level, we need with:

function F (X: T) return S;

with F;
package P is

----

At local level, you also want with?:

declare
  function F(X:T) return S;
  with F;
  package P is ...

It's becoming still weirder...

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-09 19:10, AdaMagica wrote:
> Am Donnerstag, 9. November 2017 17:58:19 UTC+1 schrieb Dmitry A. Kazakov:
>> On 2017-11-09 16:36, AdaMagica wrote:
>>>> Now the "right" way:
>>>>
>>>>       package Foo is new Bar;
>>>>       with Foo; -- For the sake of "showing dependencies"
>>>>       use Foo;  -- That's right!
>>>
>>> But that's weird.
>>>
>>> declare
>>>     package P is ... end P;
>>>     with P;  -- You really want this? Bah!
>>>     use P;
>>
>> As weird as
>>
>> with Ada.Text_IO;
>> use  Ada.Text_IO;
> 
> At library level, we need with:
> 
> function F (X: T) return S;
> 
> with F;
> package P is
> 
> ----
> 
> At local level, you also want with?:
> 
> declare
>    function F(X:T) return S;
>    with F;
>    package P is ...

Good catch!

> It's becoming still weirder...

Also why should

    with A.B.C.D;

imply

    with A, A.B, A.B.C;

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

Re: some trivial questions?

[AdaMagica]

Am Donnerstag, 9. November 2017 21:05:21 UTC+1 schrieb Dmitry A. Kazakov:
> Also why should
> 
>     with A.B.C.D;
> 
> imply
> 
>     with A, A.B, A.B.C;

Do you think it shouldn't?

Children have direct visibility of their ancestors' visible part.
So why shouldn't "with A.B" imply "with A"?

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-09 22:11, AdaMagica wrote:
> Am Donnerstag, 9. November 2017 21:05:21 UTC+1 schrieb Dmitry A. Kazakov:
>> Also why should
>>
>>      with A.B.C.D;
>>
>> imply
>>
>>      with A, A.B, A.B.C;
> 
> Do you think it shouldn't?

No. Likewise

    use A.B.C;

should imply

    with [<prefix>,] [<prefix>.]A, [<prefix>.]A.B, [<prefix>.]A.B.C;

> Children have direct visibility of their ancestors' visible part.
> So why shouldn't "with A.B" imply "with A"?

Playing devil's advocate, why visibility of A.B in C should imply that D 
depends on A.B when D has "with A.B.C;"

The point is that if deduction of dependencies is allowed in some cases 
it should be allowed everywhere. If it is not allowed somewhere it 
should not be anywhere.

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

Re: some trivial questions?

[AdaMagica]

Am Donnerstag, 9. November 2017 22:38:31 UTC+1 schrieb Dmitry A. Kazakov:
> On 2017-11-09 22:11, AdaMagica wrote:
> > Am Donnerstag, 9. November 2017 21:05:21 UTC+1 schrieb Dmitry A. Kazakov:
> >> Also why should
> >>
> >>      with A.B.C.D;
> >>
> >> imply
> >>
> >>      with A, A.B, A.B.C;
> > 
> > Do you think it shouldn't?
> 
> No. Likewise
> 
>     use A.B.C;
> 
> should imply
> 
>     with [<prefix>,] [<prefix>.]A, [<prefix>.]A.B, [<prefix>.]A.B.C;
> 
I do not understand. You don't want "with A.B" to imply "with A", but you want "use A.B" to imply "use A"?

> > Children have direct visibility of their ancestors' visible part.
> > So why shouldn't "with A.B" imply "with A"?
> Playing devil's advocate, why visibility of A.B in C should imply that D 
> depends on A.B when D has "with A.B.C;"
Then C depends on A.B, so if D depends on A.B.C, it also depends on A.B.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 09/11/2017 23:52, AdaMagica wrote:
> Am Donnerstag, 9. November 2017 22:38:31 UTC+1 schrieb Dmitry A. Kazakov:
>> On 2017-11-09 22:11, AdaMagica wrote:
>>> Am Donnerstag, 9. November 2017 21:05:21 UTC+1 schrieb Dmitry A. Kazakov:
>>>> Also why should
>>>>
>>>>       with A.B.C.D;
>>>>
>>>> imply
>>>>
>>>>       with A, A.B, A.B.C;
>>>
>>> Do you think it shouldn't?
>>
>> No. Likewise
>>
>>      use A.B.C;
>>
>> should imply
>>
>>      with [<prefix>,] [<prefix>.]A, [<prefix>.]A.B, [<prefix>.]A.B.C;
>>
> I do not understand. You don't want "with A.B" to imply "with A",
> but  you want "use A.B" to imply "use A"?

I want any obvious dependencies implied.

>>> Children have direct visibility of their ancestors' visible part.
>>> So why shouldn't "with A.B" imply "with A"?
>> Playing devil's advocate, why visibility of A.B in C should imply that D
>> depends on A.B when D has "with A.B.C;"
> Then C depends on A.B, so if D depends on A.B.C, it also depends on A.B.

Yes, and that dependency must be stated explicitly. No?

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

Re: some trivial questions?

[J-P. Rosen]

Le 09/11/2017 à 21:05, Dmitry A. Kazakov a écrit :
> Also why should
> 
>    with A.B.C.D;
> 
> imply
> 
>    with A, A.B, A.B.C;
Because if you say you import a branch, then you import a full branch.

If you want to import a single (child) unit, say so:
with A.B.C.D;
package D_Alone renames A.B.C.D;

with D_Alone;
...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-10 19:21, J-P. Rosen wrote:
> Le 09/11/2017 à 21:05, Dmitry A. Kazakov a écrit :
>> Also why should
>>
>>     with A.B.C.D;
>>
>> imply
>>
>>     with A, A.B, A.B.C;
> Because if you say you import a branch, then you import a full branch.

Why this logic does not apply to "use". When I say I use a branch don't 
I import it?

> If you want to import a single (child) unit, say so:
> with A.B.C.D;
> package D_Alone renames A.B.C.D;
> 
> with D_Alone;

And what does that say about "explicit dependencies"? This certainly 
does not mean that the package no more depends on A, A.B, A.B.C, A.B.C.D.

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

Re: some trivial questions?

[AdaMagica]

Am Freitag, 10. November 2017 20:34:19 UTC+1 schrieb Dmitry A. Kazakov:
> On 2017-11-10 19:21, J-P. Rosen wrote:
> > Le 09/11/2017 à 21:05, Dmitry A. Kazakov a écrit :
> >> Also why should
> >>
> >>     with A.B.C.D;
> >>
> >> imply
> >>
> >>     with A, A.B, A.B.C;
> > Because if you say you import a branch, then you import a full branch.
> 
> Why this logic does not apply to "use". When I say I use a branch don't 
> I import it?
> 
> > If you want to import a single (child) unit, say so:
> > with A.B.C.D;
> > package D_Alone renames A.B.C.D;
> > 
> > with D_Alone;
> 
> And what does that say about "explicit dependencies"? This certainly 
> does not mean that the package no more depends on A, A.B, A.B.C, A.B.C.D.

But the with-clause is not about dependence, it's only about visibility.

package A is ...;

with A;
package B is ...;

with B;
package C is ...;

C has visibility on B, not on A, but depends on A. Elaboration sequence is about dependence.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-11 12:32, AdaMagica wrote:

> But the with-clause is not about dependence, it's only about visibility.

The argument was that "with" is here to show dependencies.

P.S. Indirect visibility is a nonsense concept. A thing is either 
visible and that is directly visible or not visible. There is no need to 
mark anything as invisible because it could be visible if you did 
something else. Just do that else or do nothing.

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

Re: some trivial questions?

[AdaMagica]

Am Samstag, 11. November 2017 13:17:10 UTC+1 schrieb Dmitry A. Kazakov:
> P.S. Indirect visibility is a nonsense concept. A thing is either 
> visible and that is directly visible or not visible. There is no need to 
> mark anything as invisible because it could be visible if you did 
> something else. Just do that else or do nothing.

The general Ada term is "visible" comprising "directly visible", RM 8.3(2).

Direct visibility in this context is use-visibility in contrast to visibility by selection (selected_component). So I do not understand what you are trying to say. Would you favor use-clauses everywhere, i.e. (not Ada) an implied use-clause with any with-clause? But for resolving visibility conflicts, we need selector_names, so we need a term for this kind of visibility.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-11 16:38, AdaMagica wrote:

> Direct visibility in this context is use-visibility in contrast to 
> visibility by selection (selected_component). So I do not understand
> what you are trying to say.

There is no need in that concept. The same entity may be visible under 
several names like "Standard.A.B.C", "A.B.C", "C", "My_Renamed_C".

> Would you favor use-clauses everywhere,

No.

However if I designed Ada, I would pay far more attention to early 
prevention of name conflicts. Probably I would never allowed hiding, 
e.g. if multiple use clauses would hide something that should make these 
clauses illegal. I would reworked overloading in a way that each 
overloaded item would always have a distinct name, e.g. derived from the 
subprogram signature etc.

> i.e. (not Ada) an implied use-clause with any with-clause?
No.

> But for resolving visibility conflicts, we need selector_names, so we
> need a term for this kind of visibility.
It is just a name under which the entity is visible.

The discussion was around "with" used to denote dependency and "use" to 
control visibility. I agree with that separation of roles.

Now talking about visibility, the part of the with-clause related to 
visibility should rather be a use-clause. E.g. we have use-package and 
use-type clauses. It would be only logical to have use-child clause for 
the purpose of giving visibility to a specific child unit. Or maybe 
none. I would not be horrified if this were legal:

    procedure Hello_To_No_With is
    begin
       Ada.Text_IO.Put_Line ("I need no with to greet the world!");
    end Hello_To_No_With;

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

Re: some trivial questions?

[J-P. Rosen]

Le 11/11/2017 à 12:32, AdaMagica a écrit :
> But the with-clause is not about dependence, it's only about visibility.
> 
> package A is ...;
> 
> with A;
> package B is ...;
> 
> with B;
> package C is ...;
> 
> C has visibility on B, not on A, but depends on A. Elaboration sequence is about dependence.

Sorry, but I don't agree. It's about logical dependency, because it says
"if you want to understand unit C, you need to understant the
specification on B." Of course, if you want to understand B, you need to
understand A, but that's just because the with is on the spec, it
wouldn't be the case if the with were on the body.

Of course, there is some visibility issue that comes with it: if you
depend on something, it'd better be visible! But the main issue is
dependence.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: some trivial questions?

[Robert Eachus]

On Saturday, November 11, 2017 at 6:32:14 AM UTC-5, AdaMagica wrote:
> But the with-clause is not about dependence, it's only about visibility.

No!  Come on guys, the with clause does affect visibility, but it has a lot of other effects.  The use clause is only about (direct) visibility.  

However, the important thing which I have not seen mentioned here, is that the parsing for with clauses is completely different from the parsing for use clauses.  Assuming that the compiler has the concept of a library, the with clause searches the LIBRARY for compilation units and adds them to the program.  The use clause searches NAMES visible at the point of the use clause, and if legal adds the names visible in the named unit to the list of visible names. If the use clause is in a context clause, the names become (potentially) visible in the declaration following the context clause.

One of my two line compiler killers back in the early sixties (before compiler validations) was:

with Text_IO; use ASCII, Text_IO;
procedure Main is begin Put(Nul); end;

Special casing ASCII could handle this, but there are many other instances where a use clause in a context clause doesn't need to reference the same context clause, for example on the body of a package.

In 90+% of cases, a "with and use" clause would work.  It was even considered for Ada 9X.  But the problem with it was that the rules for what it meant--other than making it syntactic sugar for "with Foo; use Foo;" would be almost impossible to understand.  Trying to explain to a user why with and use failed was seen as too big an unnecessary addition to the language. Adding qualified names for compilation units (Ada.Text_IO) was considered much more important.

Re: some trivial questions?

[Jeffrey R. Carter]

On 11/14/2017 05:49 PM, Robert Eachus wrote:
> 
> One of my two line compiler killers back in the early sixties (before compiler validations) was:
> 
> with Text_IO; use ASCII, Text_IO;
> procedure Main is begin Put(Nul); end;

Ah, yes, Ada 60. I remember it well.

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ou4uvm$uuc$1@gioia.aioe.org...
...
> Why this logic does not apply to "use". When I say I use a branch don't I 
> import it?

Because package "use" is evil, and the dumber it works the better. 
(Semi-tongue-in-cheek. :-)

                      Randy.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 17/11/2017 02:11, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ou4uvm$uuc$1@gioia.aioe.org...
> ...
>> Why this logic does not apply to "use". When I say I use a branch don't I
>> import it?
> 
> Because package "use" is evil, and the dumber it works the better.
> (Semi-tongue-in-cheek. :-)

Right the logic applies only to good thins, which makes the evil ones so 
dear. (:-))

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

Re: some trivial questions?

[G. B.]

J-P. Rosen <rosen@adalog.fr> wrote:
> Le 09/11/2017 à 21:05, Dmitry A. Kazakov a écrit :
>> Also why should
>> 
>>    with A.B.C.D;
>> 
>> imply
>> 
>>    with A, A.B, A.B.C;
> Because if you say you import a branch, then you import a full branch.
> 
> If you want to import a single (child) unit, say so:
> with A.B.C.D;
> package D_Alone renames A.B.C.D;
> 
> with D_Alone;
> ...
> 

Is this an Ada jewel already?
Or a section of Ada docs at Stackoverflow?

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ou2cdt$mtf$1@gioia.aioe.org...
...
> Also why should
>
>    with A.B.C.D;
>
> imply
>
>    with A, A.B, A.B.C;

One would rather it didn't, but the "visibility holes" that would result 
caused so many semantic problems that the Ada 9x team punted. If this had 
been designed into Ada from the beginning rather than being "bolted-on" in 
Ada 95, perhaps the result would have been different.

                                                Randy.

Re: some trivial questions?

[Robert A Duff]

AdaMagica <christ-usch.grein@t-online.de> writes:

> At library level, we need with:
>
> function F (X: T) return S;

Library subprograms are an attractive nuisance.
They shouldn't exist.

> with F;
> package P is
>
> ----
>
> At local level, you also want with?:
>
> declare
>   function F(X:T) return S;
>   with F;

No.

>   package P is ...
>
> It's becoming still weirder...

- Bob

Re: some trivial questions?

[AdaMagica]

Am Donnerstag, 9. November 2017 23:43:37 UTC+1 schrieb Robert A Duff:
> AdaMagica writes:
> 
> > At library level, we need with:
> >
> > function F (X: T) return S;
> 
> Library subprograms are an attractive nuisance.
> They shouldn't exist.

Ahem - what about the main subprogram?

> > with F;
> > package P is
> >
> > ----
> >
> > At local level, you also want with?:
> >
> > declare
> >   function F(X:T) return S;
> >   with F;
> 
> No.
I didn't mean you, I meant Dmitry how seems to favor this.
> 
> >   package P is ...
> >
> > It's becoming still weirder...
> 
> - Bob

Re: some trivial questions?

[Dmitry A. Kazakov]

On 09/11/2017 23:56, AdaMagica wrote:

> I didn't mean you, I meant Dmitry how seems to favor this.

Not at all. It was mere illustration of absurdity of the argument of 
showing dependencies.

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

Re: some trivial questions?

[Robert A Duff]

AdaMagica <christ-usch.grein@t-online.de> writes:

> Ahem - what about the main subprogram?

All subprograms, including the main one, should be
inside packages.

- Bob

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-10 16:47, Robert A Duff wrote:
> AdaMagica <christ-usch.grein@t-online.de> writes:
> 
>> Ahem - what about the main subprogram?
> 
> All subprograms, including the main one, should be
> inside packages.

Could main considered a separate body of the package Ada?

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

Re: some trivial questions?

[Robert Eachus]

On Friday, November 10, 2017 at 10:54:40 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2017-11-10 16:47, Robert A Duff wrote:
> > AdaMagica <christ-usch.grein@t-online.de> writes:
> > 
> >> Ahem - what about the main subprogram?
> > 
> > All subprograms, including the main one, should be
> > inside packages.
> 
> Could main considered a separate body of the package Ada?

No, it is a descendant of Standard. See 10.1.1(10).  Better is the note in 8.1(17):  As explained above and in 10.1.1, “Compilation Units - Library Units”, all library units are descendants of Standard, and so are contained in the declarative region of Standard. They are not inside the declaration or body of Standard, but they are inside its declarative region.

Clear?  Right.  But it matters in tasking, distributed programs, and early in elaboration of a program.

Re: some trivial questions?

[Dmitry A. Kazakov]

On 14/11/2017 16:58, Robert Eachus wrote:
> On Friday, November 10, 2017 at 10:54:40 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2017-11-10 16:47, Robert A Duff wrote:
>>> AdaMagica <christ-usch.grein@t-online.de> writes:
>>>
>>>> Ahem - what about the main subprogram?
>>>
>>> All subprograms, including the main one, should be
>>> inside packages.
>>
>> Could main considered a separate body of the package Ada?
> 
> No, it is a descendant of Standard.

It was about making subprograms non-units.

> But it matters in tasking, distributed programs, and
> early in elaboration of a program.

Elaboration order might indeed be a problem if main were within 
Standard. However since Standard is pure we could require it elaborated 
last. That will bring main at the end of the list.

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

Re: some trivial questions?

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wcch8u2jfu1.fsf@TheWorld.com...
> AdaMagica <christ-usch.grein@t-online.de> writes:
>
>> Ahem - what about the main subprogram?
>
> All subprograms, including the main one, should be
> inside packages.

That's how early versions of Janus/Ada were implemented. The main was called 
by the elaboration code of a package body, typically. And even now, so far 
as the Janus/Ada compiler is concerned, a library subprogram is nested 
inside of an anonymous package, thus for code generation purposes all 
library units are equivalent.

                                          Randy.

Re: some trivial questions?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ou21f3$1bo$1@gioia.aioe.org...
...
> As weird as
>
> with Ada.Text_IO;
> use  Ada.Text_IO;

Surely no one outside of a beginning programming class actually writes this 
sort of thing. (Making the sort of pronouncement that Dmitry is famous for 
;-)

Ada.Text_IO.Put_Line isn't enough longer than just Put_Line to get any real 
value out of the use clause, and few Ada programs have that many I/O lines. 
I might put a "use Ada.Text_IO" into a routine that opens a Text_IO file, 
but that's about it.

                                   Randy.

Re: some trivial questions?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>    package Foo is new Bar;
>    use Foo; -- That must be illegal

It's not illegal, nor should it be. (Are you joking, perhaps?)

Re: some trivial questions?

[Dmitry A. Kazakov]

On 2017-11-09 19:08, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>     package Foo is new Bar;
>>     use Foo; -- That must be illegal
> 
> It's not illegal, nor should it be. (Are you joking, perhaps?)

Just following the argument of "explicit dependencies" to its logical 
end, reductio ad absurdum.

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

Re: some trivial questions?

[Jeffrey R. Carter]

On 11/06/2017 11:37 PM, Robert A Duff wrote:
> 
> Not really.  I'd prefer that both things be called "procedure".
> Then we wouldn't need the terms "function" and "subprogram".
> But we'd still need a distinction between procedures that
> return a value and those that don't.

Yes, but then we'd have something like "procedure" for both, "value-returning 
procedure" for those that return a value, and "non-value-returning procedure" 
for those that don't return a value. "Subprogram", "function", and "procedure" 
seems preferable.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: some trivial questions?

[Brian Drummond]

On Tue, 07 Nov 2017 18:41:40 +0100, Jeffrey R. Carter wrote:

> On 11/06/2017 11:37 PM, Robert A Duff wrote:
>> 
>> Not really.  I'd prefer that both things be called "procedure".
>> Then we wouldn't need the terms "function" and "subprogram". But we'd
>> still need a distinction between procedures that return a value and
>> those that don't.
> 
> Yes, but then we'd have something like "procedure" for both,
> "value-returning procedure" for those that return a value, and
> "non-value-returning procedure" for those that don't return a value.
> "Subprogram", "function", and "procedure"
> seems preferable.

How about "function" and "void function"?

(ducking and running away)
-- Brian