ANN: Ada 2005 Math Extensions, 20100810 release

ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

.. at http://sourceforge.net/projects/gnat-math-extn/.

The most obvious change is that there's a set of AUnit tests.

More subtly, the function Eigenvalues now follows the requirement "The
index range of the result is A'Range(1)." in its parent package
(http://www.adaic.com/standards/05rm/html/RM-G-3-2.html).

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Ada novice]

On Aug 10, 11:38 pm, Simon Wright <si...@pushface.org> wrote:
> .. athttp://sourceforge.net/projects/gnat-math-extn/.
>
> The most obvious change is that there's a set of AUnit tests.

Thanks. This will give me an opportunity to "play" with AUnit testing.

YC

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

I was thinking about the next release, and contemplating

   --  Obtain the eigenvalues of a non-symmetric real matrix.
   function Eigenvalues (A : Real_Matrix) return Complex_Vector;

It's easy enough to implement this in
Ada.Numerics.Generic_Complex_Arrays.Extensions, but it seems slightly
more natural to put it into Ada.Numerics.Generic_Real_Arrays.Extensions.

However, I'm puzzled about how to get Complex_Vector in there, because
it's declared in Generic_Complex_Arrays (and of course you'd want to use
the same instantiation throughout, not a local one).

Starting from the declaration of Generic_Complex_Arrays, I arrived at

   with Ada.Numerics.Generic_Complex_Arrays;
   with Ada.Numerics.Generic_Complex_Types;

   generic
      with package Complex_Types is new Ada.Numerics.Generic_Complex_Types
        (Real);
      with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays
        (Generic_Real_Arrays, Complex_Types);            -- <<<<<<<<<<<<<<<<<<
      use Complex_Arrays;
   package Ada.Numerics.Generic_Real_Arrays.Extensions is

      function Eigenvalues (A : Real_Matrix) return Complex_Vector;

   end Ada.Numerics.Generic_Real_Arrays.Extensions;

but GNAT complains about Generic_Real_Arrays where I've indicated,
saying it expects a package instance to instantiate a formal.

I'd been hoping that -- in the context of a child of
Generic_Real_Arrays -- the name would mean 'the current instantiation',
but clearly not (GNAT GPL 2010, GCC 4.5.0).

Any thoughts?

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Wed, 11 Aug 2010 22:38:46 +0100, Simon Wright wrote:

> I was thinking about the next release, and contemplating
> 
>    --  Obtain the eigenvalues of a non-symmetric real matrix.
>    function Eigenvalues (A : Real_Matrix) return Complex_Vector;
> 
> It's easy enough to implement this in
> Ada.Numerics.Generic_Complex_Arrays.Extensions, but it seems slightly
> more natural to put it into Ada.Numerics.Generic_Real_Arrays.Extensions.
> 
> However, I'm puzzled about how to get Complex_Vector in there, because
> it's declared in Generic_Complex_Arrays (and of course you'd want to use
> the same instantiation throughout, not a local one).
> 
> Starting from the declaration of Generic_Complex_Arrays, I arrived at
> 
>    with Ada.Numerics.Generic_Complex_Arrays;
>    with Ada.Numerics.Generic_Complex_Types;
> 
>    generic
>       with package Complex_Types is new Ada.Numerics.Generic_Complex_Types
>         (Real);
>       with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays
>         (Generic_Real_Arrays, Complex_Types);            -- <<<<<<<<<<<<<<<<<<
>       use Complex_Arrays;
>    package Ada.Numerics.Generic_Real_Arrays.Extensions is
> 
>       function Eigenvalues (A : Real_Matrix) return Complex_Vector;
> 
>    end Ada.Numerics.Generic_Real_Arrays.Extensions;
> 
> but GNAT complains about Generic_Real_Arrays where I've indicated,
> saying it expects a package instance to instantiate a formal.
>
> I'd been hoping that -- in the context of a child of
> Generic_Real_Arrays -- the name would mean 'the current instantiation',
> but clearly not (GNAT GPL 2010, GCC 4.5.0).

AFAIK it does not work, I tried something similar before. You cannot name
the parent package instance in the generic child declarations.
 
> Any thoughts?

(as always the first thought is: what a mess generics are! (:-))

I would not do that. It would only make instantiation tricky.
Generic_Complex_Arrays already has all types involved, so for the end user
it is much simpler when the extension package were its child.

Further I would name it 

generic
package Ada.Numerics.Generic_Complex_Arrays.
   Generic_Real_Extensions;
   ^^^^
or Generic_Real_Valued_Extensions;
   ^^^^^

It is always helpful to keep all name spaces clean of generic names.

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> Further I would name it
>
> generic
> package Ada.Numerics.Generic_Complex_Arrays.
>    Generic_Real_Extensions;
>    ^^^^
> or Generic_Real_Valued_Extensions;
>    ^^^^^
>
> It is always helpful to keep all name spaces clean of generic names.

Not quite sure what you mean here?

I think you're recommending that all names of generic units should
include an indication that they're generic, so that people don't get
confused as to generic vs instantiation?

In other places I've tacked _G on the end of the 'obvious' name:

   generic
   package ColdFrame.Events_G.Standard_G.Callback_Manager_G is

and I saw someone else (Ludovic?) doing the same here recently.


I think that people are going to get confused instantiating children of
generic packages, and that there's nothing like a helpful example to
clarify.

Currently I have (with elsewhere, "type Real is digits <>;")

   package Real_Arrays
   is new Ada.Numerics.Generic_Real_Arrays (Real);
   package Complex_Types
   is new Ada.Numerics.Generic_Complex_Types (Real);
   package Complex_Arrays
   is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays, Complex_Types);
   package Extensions
   is new Complex_Arrays.Extensions;

Do people feel this would be clearer if the last 2 lines read instead

   package Extensions
   is new Complex_Arrays.Generic_Extensions;

(and if so, how much clearer?!)

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Thu, 12 Aug 2010 20:45:33 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Further I would name it
>>
>> generic
>> package Ada.Numerics.Generic_Complex_Arrays.
>>    Generic_Real_Extensions;
>>    ^^^^
>> or Generic_Real_Valued_Extensions;
>>    ^^^^^
>>
>> It is always helpful to keep all name spaces clean of generic names.
> 
> Not quite sure what you mean here?
> 
> I think you're recommending that all names of generic units should
> include an indication that they're generic, so that people don't get
> confused as to generic vs instantiation?

More important is that names of generics do not hide other names. Sooner or
later it becomes a problem.

> In other places I've tacked _G on the end of the 'obvious' name:
> 
>    generic
>    package ColdFrame.Events_G.Standard_G.Callback_Manager_G is
> 
> and I saw someone else (Ludovic?) doing the same here recently.

I used plural suffix 's' before, but it Generic is clearer and it seems
like a semi-standard now.

> I think that people are going to get confused instantiating children of
> generic packages, and that there's nothing like a helpful example to
> clarify.
> 
> Currently I have (with elsewhere, "type Real is digits <>;")
> 
>    package Real_Arrays
>    is new Ada.Numerics.Generic_Real_Arrays (Real);
>    package Complex_Types
>    is new Ada.Numerics.Generic_Complex_Types (Real);
>    package Complex_Arrays
>    is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays, Complex_Types);
>    package Extensions
>    is new Complex_Arrays.Extensions;
> 
> Do people feel this would be clearer if the last 2 lines read instead
> 
>    package Extensions
>    is new Complex_Arrays.Generic_Extensions;
> 
> (and if so, how much clearer?!)

Yes, especially because of two "Extensions". I had immense problems with
names. Look at this:

   http://www.dmitry-kazakov.de/ada/fuzzy_packages.gif

Somewhere down deep the hierarchy the user starts to become incomprehensive
error messages upon instantiation within the generic(!) bodies. It is
practically impossible to understand what is wrong, is it a compiler bug
(in GNAT case) or something else. For the user it would be a nightmare to
fight this.

Another rule of thumb (I don't know if this is going to be fixed in Ada
2012), is that a child should always rename formal generic arguments in its
specifications. Under certain circumstances, usually in children, they
might become unavailable. I mean this:

generic
   with package P is new Generic_P (<>);
package Generic_S is
   package P_Of renames P; -- You will need this!

Sometimes you need to "rename" formal types as well:

generic
   type Foo is ...
package Generic_S is
   subtype Foo_Of is Foo; -- What a mess!

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Ludovic Brenta]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> In other places I've tacked _G on the end of the 'obvious' name:
>> 
>>    generic
>>    package ColdFrame.Events_G.Standard_G.Callback_Manager_G is
>> 
>> and I saw someone else (Ludovic?) doing the same here recently.
>
> I used plural suffix 's' before, but it Generic is clearer and it seems
> like a semi-standard now.

Yes, I did a _G here recently; I let the coding standard of Eurocontrol
(my day job) influence me.  The coding standard says *_G for generics,
*_T for secondary types and just T for types.  Hence:

package S_Expression is -- singlular
   type T is ...; -- the primary type, S_Expression.T
   generic ...
   package Serialization_G is ...
   end Serialization_G;
private
   type Internal_T is ...; -- a secondary (helper) type
end S_Expression;

Over the years I grew used to it and now I like it.  One of the
advantages is that you don't have to struggle to find meaningful names
for parameters; e.g. you can say:

procedure Foo (Internal : out Internal_T) is ...
end Foo;

-- 
Ludovic Brenta.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Fri, 13 Aug 2010 08:54:18 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Yes, I did a _G here recently; I let the coding standard of Eurocontrol
> (my day job) influence me.  The coding standard says *_G for generics,
> *_T for secondary types and just T for types.  Hence:
>
> package S_Expression is -- singlular
>    type T is ...; -- the primary type, S_Expression.T
>    generic ...
>    package Serialization_G is ...
>    end Serialization_G;
> private
>    type Internal_T is ...; -- a secondary (helper) type
> end S_Expression;
They seems to have an affinity for very short names. This would need  
evaluation (may be good at some point, less at some others)

> Over the years I grew used to it and now I like it.  One of the
> advantages is that you don't have to struggle to find meaningful names
> for parameters; e.g. you can say:
>
> procedure Foo (Internal : out Internal_T) is ...
> end Foo;
For that one, the merit does not come to _T, but rather to _Any_Suffix.  
We've talked about it already, this was about the _Type suffix. This _T  
works the same way.


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Georg Bauhaus]

On 8/13/10 8:27 AM, Dmitry A. Kazakov wrote:

> Another rule of thumb (I don't know if this is going to be fixed in Ada
> 2012), is that a child should always rename formal generic arguments in its
> specifications. Under certain circumstances, usually in children, they
> might become unavailable. I mean this:

Would you mind showing an example of a name that is needed
but unavailable?

> generic
>     with package P is new Generic_P (<>);
> package Generic_S is
>     package P_Of renames P; -- You will need this!

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Fri, 13 Aug 2010 09:42:15 +0200, Georg Bauhaus wrote:

> On 8/13/10 8:27 AM, Dmitry A. Kazakov wrote:
> 
>> Another rule of thumb (I don't know if this is going to be fixed in Ada
>> 2012), is that a child should always rename formal generic arguments in its
>> specifications. Under certain circumstances, usually in children, they
>> might become unavailable. I mean this:
> 
> Would you mind showing an example of a name that is needed
> but unavailable?

>> generic
>>     with package P is new Generic_P (<>);
>> package Generic_S is
>>     package P_Of renames P; -- You will need this!

Do you mean the use case or the offending code? I cannot say for the latter
because I have no idea when it happens and if the code is legal [*]. The
simplest possible use case is the diamond diagram of generic packages [**]:

  A
 / \
B  C
 \ /
  D

In the specification of D you have to constrain B and C to the same A. For
this you will need to refer the parameters of B and C:

   generic
   package A is end A;

   generic
      with package AA is new A (<>);
   package B is end B;

   generic
      with package AA is new A (<>);
   package C is end C;

   generic
      with package BB is new B (<>);
      with package CC is new C (BB.AA);
         -- Somewhere, somehow this ceases to work
   package D is end D;

Note that Simon's problem is the same use case (just one shoulder of the
diagram) but of different shape [*]:

   generic
   package A is end A;

   generic
   package A.B is end A.B;

   generic
   package A.C is end A.C;

   with A.B, A.C;
   generic
      with package AB is new A.B (my own A); -- No way!
      with package AC is new A.C (my own A); -- No way!
   package A.D is end D;

-----------
* Generics is a mess, remember?
** We were told how dreadful the diamond is, so bad that Ada may not allow
to have MI, but for sacred generics anything is perfectly OK!

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Fri, 13 Aug 2010 10:40:57 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Do you mean the use case or the offending code? I cannot say for the  
> latter
> because I have no idea when it happens and if the code is legal [*]. The
> simplest possible use case is the diamond diagram of generic packages  
> [**]:
>
>   A
>  / \
> B  C
>  \ /
>   D
>
> In the specification of D you have to constrain B and C to the same A.

This may also occurs if you wanna do some Mixins. This was how I came to  
it the first if my mind is right.

> ** We were told how dreadful the diamond is, so bad that Ada may not  
> allow
> to have MI, but for sacred generics anything is perfectly OK!
Did not understood this sentence, at least the last “but for sacred  
generics anything is perfectly OK!”


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Fri, 13 Aug 2010 15:41:08 +0200, Yannick Duchêne (Hibou57) wrote:

>> ** We were told how dreadful the diamond is, so bad that Ada may not allow
>> to have MI, but for sacred generics anything is perfectly OK!
> Did not understood this sentence, at least the last “but for sacred  
> generics anything is perfectly OK!”

Any problems MI is accused of do exist in generics and interfaces. But Ada
2005 had got ugly Java interfaces instead of clean MI. A combination of
Java interfaces with generics in order to achieve MI is the worst thing
ever invented.

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Fri, 13 Aug 2010 08:27:52 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> In other places I've tacked _G on the end of the 'obvious' name:
>>
>>    generic
>>    package ColdFrame.Events_G.Standard_G.Callback_Manager_G is
>>
>> and I saw someone else (Ludovic?) doing the same here recently.
>
> I used plural suffix 's' before, but it Generic is clearer and it seems
> like a semi-standard now.

You mean the _G suffis became a somewhat de-facto standard ?

> Yes, especially because of two "Extensions". I had immense problems with
> names. Look at this:
>
>    http://www.dmitry-kazakov.de/ada/fuzzy_packages.gif
Will have to look at it again, as I did not really understand this one.

> Another rule of thumb (I don't know if this is going to be fixed in Ada
> 2012), is that a child should always rename formal generic arguments in  
> its
> specifications. Under certain circumstances, usually in children, they
> might become unavailable. I mean this:
>
> generic
>    with package P is new Generic_P (<>);
> package Generic_S is
>    package P_Of renames P; -- You will need this!
>
> Sometimes you need to "rename" formal types as well:
>
> generic
>    type Foo is ...
> package Generic_S is
>    subtype Foo_Of is Foo; -- What a mess!

We already talked about these cases. Do you remember the thread's title ?  
(I would like to get it back to read it again).


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Fri, 13 Aug 2010 15:31:30 +0200, Yannick Duch�ne (Hibou57) wrote:

> You mean the _G suffis became a somewhat de-facto standard ?

I meant the prefix Generic_. However the standard has no clear policy on
that:

Ada.Text_IO.Integer_IO
Ada.Containers.Doubly_Linked_Lists
Ada.Numerics.Generic_Complex_Arrays

>> Sometimes you need to "rename" formal types as well:
>>
>> generic
>>    type Foo is ...
>> package Generic_S is
>>    subtype Foo_Of is Foo; -- What a mess!
> 
> We already talked about these cases. Do you remember the thread's title ?  
> (I would like to get it back to read it again).

I think it popped up more than once.

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> Yes, especially because of two "Extensions". I had immense problems with
> names. Look at this:
>
>    http://www.dmitry-kazakov.de/ada/fuzzy_packages.gif

Gosh!

From a UML background (OK, OK, ...) I'd have the arrows pointing the
other way ('depends on' rather than 'is used in' or 'supports').

> Somewhere down deep the hierarchy the user starts to become
> incomprehensive error messages upon instantiation within the
> generic(!) bodies. It is practically impossible to understand what is
> wrong, is it a compiler bug (in GNAT case) or something else. For the
> user it would be a nightmare to fight this.

I think I've come across a GNAT bug here .. I dont think it's allowed
for a generic to compile but the instantiation not!

> Another rule of thumb (I don't know if this is going to be fixed in
> Ada 2012), is that a child should always rename formal generic
> arguments in its specifications. Under certain circumstances, usually
> in children, they might become unavailable. I mean this:
>
> generic
>    with package P is new Generic_P (<>);
> package Generic_S is
>    package P_Of renames P; -- You will need this!
>
> Sometimes you need to "rename" formal types as well:
>
> generic
>    type Foo is ...
> package Generic_S is
>    subtype Foo_Of is Foo; -- What a mess!

I've more often come across the latter.

Could consider

generic
   type Formal_Foo is ...
package Generic_S is
   subtype Foo is Formal_Foo;

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon@pushface.org> a  
écrit:
> I've more often come across the latter.
>
> Could consider
>
> generic
>    type Formal_Foo is ...
> package Generic_S is
>    subtype Foo is Formal_Foo;
>
The trouble with this one, is that it move the case to the client side...  
I would not like to generic instantiations “obfuscated” with all of those  
Formal_Foo (I always use named parameter associations... especially with  
generic instantiations).

The Dmitry way, which is also the one I use, end to be less intrusive, as  
the client of the generic package is less likely to have to spell this  
somewhere (except if it/he/she has to use a formal parameter of a given  
instantiated package to instantiate another).


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon@pushface.org>
> a écrit:
>> I've more often come across the latter.
>>
>> Could consider
>>
>> generic
>>    type Formal_Foo is ...
>> package Generic_S is
>>    subtype Foo is Formal_Foo;
>>
> The trouble with this one, is that it move the case to the client
> side... I would not like to generic instantiations “obfuscated” with
> all of those  Formal_Foo (I always use named parameter
> associations... especially with  generic instantiations).
>
> The Dmitry way, which is also the one I use, end to be less intrusive,
> as the client of the generic package is less likely to have to spell
> this  somewhere (except if it/he/she has to use a formal parameter of
> a given  instantiated package to instantiate another).

Well, I couldn't see how Dmitry's "Foo_Of" would make sense as it was
being read.

   procedure P (Q : Generic_S.Foo_Of);   -- huh?

I suppose one could say

   generic
      type Foo is ...
   package Generic_S is
      subtype Actual_Foo is Foo;

(since we're adopting the "spelt-out prefix" style, Generic_, rather
than the "abbreviated suffix" style, _G !)

though I see that the last time I used it was the other way round ..

   generic
      type Actual_Foo is ...
   package Generic_S is
      subtype Foo is Actual_Foo;

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Sat, 14 Aug 2010 00:04:17 +0200, Simon Wright <simon@pushface.org> a  
écrit:
>> Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon@pushface.org>
> Well, I couldn't see how Dmitry's "Foo_Of" would make sense as it was
> being read.
>
>    procedure P (Q : Generic_S.Foo_Of);   -- huh?
>
> I suppose one could say
>
>    generic
>       type Foo is ...
>    package Generic_S is
>       subtype Actual_Foo is Foo;

I said too much less, sorry, so you could not understand what I was to say

I would rather write

generic
    type Foo is ...
package Generic_S is
    subtype Formal_Foo is Foo;

The name is not the same as the one Dmitry suggested, while the principle  
is the same : name formal parameter after the name their should have, and  
use renamed subtype in the package (just the name vary, and indeed it  
should be expressive and clear enough).

>    procedure P (Q : Generic_S.Foo_Of);   -- huh?

This would turn this into

    procedure P (Q : Generic_S.Foo_Of);

which is also not so much used for me (do not know for others who live  
with other cases in mind). The count of generic instantiations is bigger  
than the one reference to this Package_Name.Formal_Subtype, which by the  
way, mainly appears as generic parameters when needed, like “package  
Blabla_Instance is new Generic_Blabla (Blabla_Base_Type =>  
Instantiated_Package.Formal_Type);”

These Formal_Subtype_Name are most of time not part of what is provided by  
the package (otherwise, it would simply provide nothing except what  
already exists), so as most of time not referenced when what the package  
provided is referenced (from the client side). But this may be required to  
make reference to a package's formal parameters with mixins (if I am not  
wrong, I had this requirement with some kind mixins).

Pretty sure this is not so much referenced by clients, for the reason  
given above, that this is not what a package mainly provides. This is most  
needed to link generic packages each others. So (providing the latter  
assumption is OK), giving a proper name to formal parameters and only give  
special names to subtype of these formals, is likely to avoid to have to  
deal with obfuscated names as much as possible.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Sat, 14 Aug 2010 00:28:48 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> This would turn this into
>
>     procedure P (Q : Generic_S.Foo_Of);
Posted to early.

Please read instead


> This would turn this into
>
>     procedure P (Q : Generic_S.Formal_Foo);

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

>>    procedure P (Q : Generic_S.Foo_Of);   -- huh?
>
> This would turn this into
>
>    procedure P (Q : Generic_S.Foo_Of);

Sorry. Hoping not to annoy anyone further ...

I meant, as a native English speaker, I don't understand what Dmitry
meant when he tacked _Of on the end. There's no English grammatical
construction that that corresponds to.

If Ada syntax was reversed, "Foo_Of.Generic_S", it would make sense (as
an English phrase).

Maybe it's different in other languages? I have a feeling that in
French you might write "Generic_S.Son_Foo" and have it match some
natural sentence order??

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Sat, 14 Aug 2010 17:12:23 +0100, Simon Wright wrote:

> "Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> 
>>>    procedure P (Q : Generic_S.Foo_Of);   -- huh?
>>
>> This would turn this into
>>
>>    procedure P (Q : Generic_S.Foo_Of);
> 
> Sorry. Hoping not to annoy anyone further ...
> 
> I meant, as a native English speaker, I don't understand what Dmitry
> meant when he tacked _Of on the end. There's no English grammatical
> construction that that corresponds to.

I did it merely because Of_Foo would be worse.

Only after you wrote it I became aware that this is a grammar issue. "may I
end a sentence with a preposition" gives 2,580,000 results in Google.
People are running polls. Wow!

My Michael Swan's "Practical English Usage" just gives constructions where
a preposition is put at the ends of clauses:

wh-questions: "Who for?"
relative clauses: "That's what I'm afraid of"
passives: "I hate being laughed at"
infinitive structures: "Their house isn't easy to get to"

without any comments about the ongoing battle...

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Jeffrey Carter]

On 08/14/2010 10:16 AM, Dmitry A. Kazakov wrote:
>
> Only after you wrote it I became aware that this is a grammar issue. "may I
> end a sentence with a preposition" gives 2,580,000 results in Google.
> People are running polls. Wow!

As someone once said on the subject, "That is something up with which I will not 
put."

Ending a sentence with a preposition, along with split infinitives and double 
negatives, are things that were quite common and acceptable before the 19th 
century. In the 19th C logicians came up with these rules that were contrary to 
common usage, and they were adopted by like-thinkers, but the real rule is that 
they are perfectly natural usage.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> On 08/14/2010 10:16 AM, Dmitry A. Kazakov wrote:
>>
>> Only after you wrote it I became aware that this is a grammar issue. "may I
>> end a sentence with a preposition" gives 2,580,000 results in Google.
>> People are running polls. Wow!
>
> As someone once said on the subject, "That is something up with which
> I will not put."
>
> Ending a sentence with a preposition, along with split infinitives and
> double negatives, are things that were quite common and acceptable
> before the 19th century. In the 19th C logicians came up with these
> rules that were contrary to common usage, and they were adopted by
> like-thinkers, but the real rule is that they are perfectly natural
> usage.

Quite. But Foo_Of is *not* natural!

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Georg Bauhaus]

On 8/14/10 9:18 PM, Simon Wright wrote:
> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  writes:
>
>> On 08/14/2010 10:16 AM, Dmitry A. Kazakov wrote:
>>>
>>> Only after you wrote it I became aware that this is a grammar issue. "may I
>>> end a sentence with a preposition" gives 2,580,000 results in Google.
>>> People are running polls. Wow!
>>
>> As someone once said on the subject, "That is something up with which
>> I will not put."
>>
>> Ending a sentence with a preposition, along with split infinitives and
>> double negatives, are things that were quite common and acceptable
>> before the 19th century. In the 19th C logicians came up with these
>> rules that were contrary to common usage, and they were adopted by
>> like-thinkers, but the real rule is that they are perfectly natural
>> usage.
>
> Quite. But Foo_Of is *not* natural!

Being east of GMT, too, I believe I understand Dmitry's intent.
I'd replace the "inverted possessive construct with implicit whole"
with one of your suggestions, e.g., and feel a lot better,
even though my native language isn't English.

generic
    type Fur is private;
package Mechanical_Dog is
    --subtype Fur_Of is Fur; -- eastern pidgin?
    subtype Its_Fur is Fur;
    subtype Dogs_Fur is Fur;
    subtypeFormal_Fur is Fur;
    subtype Actual_Fur is Fur;
    subtype Fur_Type is Fur;
    subtype Generic_Fur is Fur;


Georg

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Yannick Duchêne (Hibou57)]

Le Sun, 15 Aug 2010 01:51:42 +0200, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> generic
>     type Fur is private;
> package Mechanical_Dog is
>     --subtype Fur_Of is Fur; -- eastern pidgin?
lol

>     subtype Its_Fur is Fur;
Looks like OO oriented talks. Talks about a generic instance as if it was  
an object (it is is some way). Why not, may be nice.

>     subtype Dogs_Fur is Fur;
Will change all other the time. Could not be a constant naming convention.

>     subtype Formal_Fur is Fur;
I know this one :p

>     subtype Actual_Fur is Fur;
Hmmm, looke like more friendly than Formal_Fur. I may switch to this one.

>     subtype Fur_Type is Fur;
Will clash in context where ZZZ_Type is already a naming convention for  
types (you will have Fur_Type_Type)

>     subtype Generic_Fur is Fur;
Personally don't like it. This tag the type with the word Generic instead  
of the package. And this would not be nice for people using Generic_ZZZ  
for packages (seems they are numerous) here


My vote goes to either Its_Fur or Actual_Fur (or Its_Fur_Type and  
Actual_Fur_Type).

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Jeffrey Carter]

On 08/14/2010 04:51 PM, Georg Bauhaus wrote:
> generic
> type Fur is private;
> package Mechanical_Dog is
> --subtype Fur_Of is Fur; -- eastern pidgin?
> subtype Its_Fur is Fur;
> subtype Dogs_Fur is Fur;
> subtypeFormal_Fur is Fur;
> subtype Actual_Fur is Fur;
> subtype Fur_Type is Fur;
> subtype Generic_Fur is Fur;

The PragmAda Reusable Components have

generic -- PragmARC.Math.Functions
    type Supplied_Real is digits <>;
package PragmARC.Math.Functions is
    pragma Pure;

    subtype Real is Supplied_Real'Base;

This is a different case (naming the base type to use for subprogram parameters, 
to eliminate any constraints on the actual for Supplied_Real), but may suggest 
something useful to someone.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Starting from the declaration of Generic_Complex_Arrays, I arrived at
>
>    with Ada.Numerics.Generic_Complex_Arrays;
>    with Ada.Numerics.Generic_Complex_Types;
>
>    generic
>       with package Complex_Types is new Ada.Numerics.Generic_Complex_Types
>         (Real);
>       with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays
>         (Generic_Real_Arrays, Complex_Types);            -- <<<<<<<<<<<<<<<<<<
>       use Complex_Arrays;
>    package Ada.Numerics.Generic_Real_Arrays.Extensions is
>
>       function Eigenvalues (A : Real_Matrix) return Complex_Vector;
>
>    end Ada.Numerics.Generic_Real_Arrays.Extensions;
>
> but GNAT complains about Generic_Real_Arrays where I've indicated,
> saying it expects a package instance to instantiate a formal.

What is the actual error message? this idiom works for me in SAL:

generic
   with package Elementary is new Ada.Numerics.Generic_Elementary_Functions (Real_Type);
   with package Math_Scalar is new SAL.Gen_Math.Gen_Scalar (Elementary);
package SAL.Gen_Math.Gen_DOF_3 is


> I'd been hoping that -- in the context of a child of
> Generic_Real_Arrays -- the name would mean 'the current instantiation',
> but clearly not (GNAT GPL 2010, GCC 4.5.0).

Post complete code, I'll try it on my version of gnat.

-- 
-- Stephe

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[sjw]

On Aug 12, 11:36 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:

> Post complete code, I'll try it on my version of gnat.

Thanks.

Remember -gnatpg!

The code I posted above is the complete spec (not going to bother to
write the body if can't get the spec to compile!):

   with Ada.Numerics.Generic_Complex_Arrays;
   with Ada.Numerics.Generic_Complex_Types;

   generic
      with package Complex_Types is new
Ada.Numerics.Generic_Complex_Types
        (Real);
      with package Complex_Arrays is new
Ada.Numerics.Generic_Complex_Arrays
        (Generic_Real_Arrays, Complex_Types);            --
<<<<<<<<<<<<<<<<<<
      use Complex_Arrays;
   package Ada.Numerics.Generic_Real_Arrays.Extensions is

      function Eigenvalues (A : Real_Matrix) return Complex_Vector;

   end Ada.Numerics.Generic_Real_Arrays.Extensions;

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> On Aug 12, 11:36 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
>> Post complete code, I'll try it on my version of gnat.
>
> Thanks.
>
> Remember -gnatpg!
>
> The code I posted above is the complete spec (not going to bother to
> write the body if can't get the spec to compile!):
>
>    with Ada.Numerics.Generic_Complex_Arrays;
>    with Ada.Numerics.Generic_Complex_Types;
>
>    generic
>       with package Complex_Types is new Ada.Numerics.Generic_Complex_Types (Real);
>       with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays
>         (Generic_Real_Arrays, Complex_Types);

I see the problem. Generic_Real_Arrays is the name of the parent generic
package; that's not a concrete package, so it can't be used here.


>    use Complex_Arrays; 
>    package Ada.Numerics.Generic_Real_Arrays.Extensions is
>
>       function Eigenvalues (A : Real_Matrix) return Complex_Vector;
>
>    end Ada.Numerics.Generic_Real_Arrays.Extensions;

This compiles:

with Ada.Numerics.Generic_Complex_Arrays;
with Ada.Numerics.Generic_Complex_Types;
with Ada.Numerics.Generic_Real_Arrays;
generic
   type Real is digits <>;
   with package Real_Arrays is new Ada.Numerics.Generic_Real_Arrays (Real);
   with package Complex_Types is new Ada.Numerics.Generic_Complex_Types (Real);
   with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays, Complex_Types);
package Extensions is

   function Eigenvalues (A : Real_Arrays.Real_Matrix) return Complex_Arrays.Complex_Vector;

end Extensions;

Is there some reason you want Extensions to be a child of Generic_Real_Arrays?

-- 
-- Stephe

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> sjw <simon.j.wright@mac.com> writes:

>>    generic
>>       with package Complex_Types is new Ada.Numerics.Generic_Complex_Types (Real);
>>       with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays
>>         (Generic_Real_Arrays, Complex_Types);
>
> I see the problem. Generic_Real_Arrays is the name of the parent generic
> package; that's not a concrete package, so it can't be used here.

Exactly so.

> This compiles:
>
> with Ada.Numerics.Generic_Complex_Arrays;
> with Ada.Numerics.Generic_Complex_Types;
> with Ada.Numerics.Generic_Real_Arrays;
> generic
>    type Real is digits <>;
>    with package Real_Arrays is new Ada.Numerics.Generic_Real_Arrays (Real);
>    with package Complex_Types is new Ada.Numerics.Generic_Complex_Types (Real);
>    with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays, Complex_Types);
> package Extensions is
>
>    function Eigenvalues (A : Real_Arrays.Real_Matrix) return Complex_Arrays.Complex_Vector;
>
> end Extensions;
>
> Is there some reason you want Extensions to be a child of
> Generic_Real_Arrays?

Umm.

In the past, I've often introduced "extensions' in child (generic)
packages, usually because the extension needed visibility of the private
part of the original. That's not so in this case, as it happens, but I
find the idiom comfortable.

Given that, the function taking Complex_Matrix and returning
Complex_Vector has "obviously" to be in a child of
Generic_Complex_Arrays.

So I thought that the function taking Real_Matrix should be in a child
of Generic_Real_Arrays, in spite of the fact it returns a Complex_Vector.

Clearly this is not the way Nature intended!

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Sat, 14 Aug 2010 17:26:20 +0100, Simon Wright wrote:

> Given that, the function taking Complex_Matrix and returning
> Complex_Vector has "obviously" to be in a child of
> Generic_Complex_Arrays.
> 
> So I thought that the function taking Real_Matrix should be in a child
> of Generic_Real_Arrays, in spite of the fact it returns a Complex_Vector.
> 
> Clearly this is not the way Nature intended!

Hmm, a complex valued function is complex to me. Consider exp(jwt). The
argument is real t, the result is complex. Where does it belong?

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> On Sat, 14 Aug 2010 17:26:20 +0100, Simon Wright wrote:
>
>> Given that, the function taking Complex_Matrix and returning
>> Complex_Vector has "obviously" to be in a child of
>> Generic_Complex_Arrays.
>> 
>> So I thought that the function taking Real_Matrix should be in a child
>> of Generic_Real_Arrays, in spite of the fact it returns a Complex_Vector.
>> 
>> Clearly this is not the way Nature intended!
>
> Hmm, a complex valued function is complex to me. Consider exp(jwt). The
> argument is real t, the result is complex. Where does it belong?

I think maybe I'll meet Stephe halfway: Ada.Numerics.Generic_Arrays!

Another problem, of course .. Ada 2017 might implement something in this
space.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Sat, 14 Aug 2010 20:16:31 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 14 Aug 2010 17:26:20 +0100, Simon Wright wrote:
>>
>>> Given that, the function taking Complex_Matrix and returning
>>> Complex_Vector has "obviously" to be in a child of
>>> Generic_Complex_Arrays.
>>> 
>>> So I thought that the function taking Real_Matrix should be in a child
>>> of Generic_Real_Arrays, in spite of the fact it returns a Complex_Vector.
>>> 
>>> Clearly this is not the way Nature intended!
>>
>> Hmm, a complex valued function is complex to me. Consider exp(jwt). The
>> argument is real t, the result is complex. Where does it belong?
> 
> I think maybe I'll meet Stephe halfway: Ada.Numerics.Generic_Arrays!
> 
> Another problem, of course .. Ada 2017 might implement something in this
> space.

If you don't make it a child you can leave the Ada's name space:

   package Linear_Algebra.Generic_Eigenvaues_Problem

or something alike.

Regarding Stephe's proposal, independently on the package name you use, I
would suggest this:

with Ada.Numerics.Generic_Complex_Arrays;
generic
   with package Complex_Arrays is
      new Ada.Numerics.Generic_Complex_Arrays (<>);
package Whatever is
   use Complex_Arrays;
   use Complex_Types;  -- Complex_Arrays.Complex_Types
   use Real_Arrays;        -- Complex_Arrays.Real_Arrays

   function Eigenvalues (A : Real_Matrix) return  Complex_Vector;
end Whatever;

You do not need to pass all chain of Generic_Complex_Arrays' arguments,
instead you pick its parameter. This technique greatly simplifies
instantiations.

BTW, this is exactly the case where you might like to rename Complex_Arrays
and others. These unnatural names xxx_Of! (:-)) I am not sure if renaming
is still actual, but it was necessary before. And I have no idea if that
was because of a compiler or language design bug.

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> with Ada.Numerics.Generic_Complex_Arrays;
> generic
>    with package Complex_Arrays is
>       new Ada.Numerics.Generic_Complex_Arrays (<>);
> package Whatever is
>    use Complex_Arrays;
>    use Complex_Types;  -- Complex_Arrays.Complex_Types
>    use Real_Arrays;        -- Complex_Arrays.Real_Arrays
>
>    function Eigenvalues (A : Real_Matrix) return  Complex_Vector;
> end Whatever;

Not sure this is _quite_ the name I was looking for :-)

I found that I could say

   package body Whatever is

      subtype Real is Complex_Arrays.Real_Arrays.Real;

So I can see the formal parameters of a formal package! (I knew that
really, that's how signature packages work).

This really seems like the best way to go. Thanks to you and Stephe for
the pointers.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Sat, 14 Aug 2010 22:55:05 +0100, Simon Wright wrote:

> I found that I could say
> 
>    package body Whatever is
> 
>       subtype Real is Complex_Arrays.Real_Arrays.Real;

Yes you can, but don't. I used this pattern before and ran into problems
with this, when in some contexts one Real conflicted with / hid another, so
that a compiled generic package could not be instantiated. (Again, no idea
if that was a compiler bug or not.)

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

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Simon Wright]

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

> On Sat, 14 Aug 2010 22:55:05 +0100, Simon Wright wrote:
>
>> I found that I could say
>> 
>>    package body Whatever is
>> 
>>       subtype Real is Complex_Arrays.Real_Arrays.Real;
>
> Yes you can, but don't. I used this pattern before and ran into problems
> with this, when in some contexts one Real conflicted with / hid another, so
> that a compiled generic package could not be instantiated. (Again, no idea
> if that was a compiler bug or not.)

In this case I had to use Complex_Arrays.Real_Arrays.Real because of the
sort of problems you indicate. So naming it seemed like a good idea.

Re: ANN: Ada 2005 Math Extensions, 20100810 release

[Dmitry A. Kazakov]

On Sun, 15 Aug 2010 18:06:51 +0100, Simon Wright wrote:

> In this case I had to use Complex_Arrays.Real_Arrays.Real because of the
> sort of problems you indicate.

One part of that problem was that such names became mysteriously hidden
upon instantiation in the generic bodies. The compiler claimed that Real
was not declared in Real_Arrays, or that Real_Arrays was not declared in
Complex_Arrays, or that Real does not match the type Real of Real_Arrays
etc. It was the worst kind of error I ever had. You have 20+ generic units.
Every body compiles. Then in a chain of 20 generic instantiations #15
fails. You try another variant, refactor this, that, rewrite parent's
children to their parameters or reverse. Two weeks later #17 fails. You
cannot test anything before a modification cycle is complete, because first
10 instantiations are always fine. Basically this is how we are accustomed
to work with C++ templates, but not with Ada. It is stable now, but anxiety
flows through my bones each time I try a new GNAT on it...

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