Containers with Ada

Containers with Ada

[jeltsch]

Hello Ada programmers,
I want to write some generic packages for container types - at the moment for
several kinds of lists. At the beginning of this work I thought this wouldn't
be that difficult but now after being faced with a lots of problems I
sometimes wonder if I should go back to C++.
Below I will present some of the difficulties. I would be very pleased if
someone could help me creating problem-oriented packages for containers which
use the advantages of Ada. I hardly can imagine that there are no really good
container implementations in Ada at the moment so there must be a solution.
Now the problems in detail:
   1. Copying of large data structures
   In my opinion one main problem of Ada is implicit copying of variables. So
   it's no good idea to define such a intuitive function like
      function Element_At(Current_List : in List; Current_Index : in Index)
                         return Element;
   In this example the list which could contain thousands of elements would
   be copied just to get one element out of it. In addition if Element is also
   a list the return statement inside Element_At would copy this list.
   A first solution could be to define List as limited. But this would be bad
   if Element is non-limited because in this case it would make sense to copy
   lists and to check them for equality. Moreover Element would have to be
   definded as limited to allow lists of lists.
   One could also totally avoid "normal" list parameters and use only access
   parameters for lists. But that would mean that every list would have to be
   aliased and that no constant parameters could be used because acces
   parameters cannot be constant.
   I took the first solution - defining lists limited and having limited
   element types. This has also advantages because lists with other limited
   element types become possible. But there are still problems of accessing
   list elements as explained in the next section.

   2. Complicated use of element access with generic procedures
   Accessing a limited element of a limited list which is not visible from
   outside the package is as far as I can see only possible in two ways - via
   an access value to the element returned by some package subprogram or by a
   generic subprogram as explained below. The first way is in my eyes
   inacceptable because the access type needed would have to be defined at the
   level of the list package instance which would the package user allow to
   have "dangling pointers".
   The approach I have taken is to define some generic procedures which have a
   a procedure as generic parameter. Here are those procedures:
      generic
         with procedure Edit_Single_Element(Current_Element : in out Element);
      procedure Edit_Element(Current_List  : in out List;
                             Current_Index : in Index);
      generic
         with procedure Read_Single_Element(Current_Element : in out Element);
      procedure Read_Element(Current_List  : in List;
                             Current_Index : in Index);
   An instance of Edit_Element or Read_Element will call Edit_Single_Element
   or Read_Single_Element respectively on the element of Current_List denoted
   by Current_Index. That seems to work just fine but it is very complicated
   to use. The following example for instance just copies the elements of
   Source_List to Dest_List.
      for Current_Index in Index range Start .. End loop
         declare
            procedure Using_Dest_Element(Dest_Element : in out Element) is
               procedure Using_Source_Element(Source_Element : in Element) is
               begin
                  Dest_Element := Source_Element;
               end Using_Source_Element;
               procedure Using_Source_List is
                  new Read_Element(Using_Source_Element);
            begin
               Using_Source_List(Source_List, Current_Element);
            end Using_Dest_Element;
            procedure Using_Dest_List is
               new Edit_Element(Using_Dest_Element);
         begin
            Using_Dest_List(Dest_List, Current_Index)
         end;
      end loop;
   In comparison the same problem with arrays:
      for Current_Index in Index range Start .. End loop
         Dest_Array(Current_Index) := Source_Array(Current_Index);
      end loop;
   or just
      Dest_Array(Start .. End) := Source_Array(Start .. End);

   3. High memory consumption with unconstrained arrays
   An easy way to define a type for lists with fixed length would be for
   instance
      type Element_Array is array(Positive range <>) of Element;
      type List(Length : Natural) is record
         Elements : Element_Array(1 .. Length);
      end record;
   With this implementation one could even think of making the whole type
   definition public. But one cannot expect that a compiler will generate code
   that dynamically allocates memory that is just enough for Elements. As I
   can see GNAT doesn't operate with implicit pointers to dynamically
   allocated memory but sets the size of List so that it is big enough for
   every value for Length. In the above example that means that every List
   would (try to) consume about 2 GB of memory on my platform.

   4. Limitations with controlled types
   Because I cannot use unconstrained arrays like in the above example I use
   pointers to arrays (access values). A good implementation should free all
   memory consumed by the list when the list ceases to exist. List should
   therefore be derived from Limited_Controlled an have a Finalize procedure
   which deallocates the element array(s). But controlled types can be only
   defined at the library level. So the following example is not possible
   which is inacceptable for me:
      procedure Act(Limit : in Natural) is
         subtype My_Range is Natural range 1 .. Limit;
         package My_Lists is new Lists(My_Range);
      begin
         ...
      end Act;
Bye, Wolfgang


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Ken Garlington]

<jeltsch@my-deja.com> wrote in message news:8v8pii$dvo$1@nnrp1.deja.com...


:    1. Copying of large data structures
:    In my opinion one main problem of Ada is implicit copying of variables.
So
:    it's no good idea to define such a intuitive function like
:       function Element_At(Current_List : in List; Current_Index : in
Index)
:                          return Element;
:    In this example the list which could contain thousands of elements
would
:    be copied just to get one element out of it.

If List contains "thousands of elements", I suspect it's probably not an
elementary type [Ada Reference Manual 3.2:3]. (It may _reference_ them, but
then only the reference is being passed, not the elements). Therefore, it
doesn't have to be passed by copy [ARM 6.2:3], and most compilers won't.
Similar rules apply to the returned value. It may be a good idea to declare
List a limited type, but not for reasons of controlling the passing
convention.

:    2. Complicated use of element access with generic procedures

Making a type limited does impose some "complications" (an investment that
yields impressive returns when used in the right way at the right time), but
since you don't have to declare the type limited for performance reasons, I
assume this is no longer an issue.

:    3. High memory consumption with unconstrained arrays

:    An easy way to define a type for lists with fixed length would be for
:    instance
:       type Element_Array is array(Positive range <>) of Element;
:       type List(Length : Natural) is record
:          Elements : Element_Array(1 .. Length);
:       end record;
:    With this implementation one could even think of making the whole type
:    definition public. But one cannot expect that a compiler will generate
code
:    that dynamically allocates memory that is just enough for Elements. As
I
:    can see GNAT doesn't operate with implicit pointers to dynamically
:    allocated memory but sets the size of List so that it is big enough for
:    every value for Length. In the above example that means that every List
:    would (try to) consume about 2 GB of memory on my platform.

There's nothing in the standard that requires this for the _exact_ example
you post, AFAIK. If you really think you're seeing this, you may want to
contact GNAT. Note that replacing "Length : Natural" with "Length : Natural
:= 0" will cause the behavior you describe, as well as a potential GNAT
message - "warning: creation of object of this type may raise
Storage_Error.". That _is_ consistent with the standard.

Here's a sample program I just tried with GNAT 3.12p for Windows, default
switches (e.g. no optimizations). It ran immediately on my machine, which
shouldn't be the case for the behavior you describe:

-- Test_Data_Structure.ads
package Test_Data_Structure is
  subtype Element is Character;
  type Element_Array is array(Positive range <>) of Element;
  type List(Length : Natural) is record
     Elements : Element_Array(1 .. Length) := (others => '?');
  end record;
end Test_Data_Structure;

-- Make_Data_Structure.adb
with Ada.Text_IO, Test_Data_Structure;
procedure Make_Data_Structure is
  package Test renames Test_Data_Structure;
  List_1 : Test.List(1);
  List_2 : Test.List(2);
  List_3 : Test.List(3);
  List_4 : Test.List(4);
begin
  Ada.Text_IO.Put(List_1.Elements(1));
  Ada.Text_IO.Put(List_2.Elements(2));
  Ada.Text_IO.Put(List_3.Elements(3));
  Ada.Text_IO.Put(List_4.Elements(4));
  Ada.Text_IO.New_Line;
end Make_Data_Structure;

:    4. Limitations with controlled types
:    Because I cannot use unconstrained arrays like in the above example

Hopefully, now you can!

Re: Containers with Ada

[Robert Dewar]

In article <8v8pii$dvo$1@nnrp1.deja.com>,
  jeltsch@my-deja.com wrote:
>    1. Copying of large data structures
>    In my opinion one main problem of Ada is implicit copying
> of variables. So
>    it's no good idea to define such a intuitive function like
>       function Element_At(Current_List : in List;
Current_Index : in Index)
>                          return Element;
>    In this example the list which could contain thousands of
elements would
>    be copied just to get one element out of it.


This is such a fundamental misconception, that you need to
go back and start at square one. No compiler I can imagine
would decide that it was more efficient to copy this list
if it had thousands of elements.

You seem to have somehow picked up the idea that IN parameters
are always copied. This of course is NOT the case in Ada.
Indeed the expectation is precisely that large objects passed
as IN parameters will be passed by reference. The compiler makes
the choice based on what is most efficient. YOU are NOT in the
business of worrying about efficiency at this level, and as
you show, if you do start worrying, you are very likely to get
yourself seriously confused :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Robert Dewar]

In article <8v8pii$dvo$1@nnrp1.deja.com>,
  jeltsch@my-deja.com wrote:
>    3. High memory consumption with unconstrained arrays
>    An easy way to define a type for lists with fixed length
> would be for
>    instance
>       type Element_Array is array(Positive range <>) of
>                                                    Element;
>       type List(Length : Natural) is record
>          Elements : Element_Array(1 .. Length);
>       end record;
>    With this implementation one could even think of making the
> whole type
>    definition public. But one cannot expect that a compiler
> will generate code
>    that dynamically allocates memory that is just enough for
> Elements. As I
>    can see GNAT doesn't operate with implicit pointers to
> dynamically
>    allocated memory but sets the size of List so that it is
> big enough for
>    every value for Length.

Nope, that's completely wrong. When there are no default
discriminants, the language requires that only the necessary
storage for the particular value be allocated, and that's
how GNAT is working. Most likely you are confused about the
role of default discriminants (although the example you gave
does not contain any). The use of default discriminants has
profound affects on the way storage is allocated.

I would suggest posting complete small examples and asking
direct questions about these examples. When you post large
brush statements based on incorrect assumptions, it is hard
to know where to start to help!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Robert Dewar]

In article <8v8pii$dvo$1@nnrp1.deja.com>,
  jeltsch@my-deja.com wrote:
atform.
>
>    4. Limitations with controlled types
>       procedure Act(Limit : in Natural) is
>          subtype My_Range is Natural range 1 .. Limit;
>          package My_Lists is new Lists(My_Range);
>       begin
>          ...
>       end Act;

Simply define the types and instantiations you need at the
library level, and parametrize them appropriately. Again,
if you post complete examples, it may be easier to help.

You are making the mistake of having a preconceived idea
of how to do things, and unfortunately the idea is wrong.
Try describing what you want to do at a high level, rather
than providing solutions that are wrong and complaining
about the solutions not working.

The trouble with the latter approach is that then we have to
guess at the problem you are trying to solve, and this guessing
often goes astray.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Robert Dewar]

It is by the way a definite limitation in Ada 95 that some
facilities of the language do not extend fully to nested
subprograms (though not quite as much a limitation as not
having nested subprograms at all, as in C or C++ :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Marc A. Criley]

jeltsch@my-deja.com wrote:
> 
> Hello Ada programmers,
> I want to write some generic packages for container types - at the moment for
> several kinds of lists.

Why?

Numerous generic packages for container types already exist--the
original Booch components, the Ada 95 Booch components, the Ada
Structured Library (my personal favorite), PragmAda, and so on.

I would much rather see an individual extend Ada's reach into new fields
in which there's little or no Ada presence, rather than reworking the
same, tired old ground.

Curmudgeonly,

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation

Re: Containers with Ada

[Ted Dennison]

In article <Pine.BSF.4.21.0011192024450.493-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> I guess for my tastes these restrictions one inherits from the use of
> controlled types with respect to nested subprograms makes their use
> for container libraries problematic. I use nested subprograms a lot,

Its not just controlled types, but derived tagged types in general.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Brian Rogoff]

On Mon, 20 Nov 2000, Ted Dennison wrote:
> In article <Pine.BSF.4.21.0011192024450.493-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> 
> > I guess for my tastes these restrictions one inherits from the use of
> > controlled types with respect to nested subprograms makes their use
> > for container libraries problematic. I use nested subprograms a lot,
> 
> Its not just controlled types, but derived tagged types in general.

Yes, I know that. However, one might want to use controlled types even
while they don't want to use tagged types. Ada unifies (confuses :) the 
two notions so you don't have a choice. 

-- Brian

Re: Containers with Ada

[Brian Rogoff]

On Mon, 20 Nov 2000, Marc A. Criley wrote:
> jeltsch@my-deja.com wrote:
> > 
> > Hello Ada programmers,
> > I want to write some generic packages for container types - at the moment for
> > several kinds of lists.
> 
> Why?

Maybe he doesn't like what's already out there, and thinks he can do
better. Maybe he doesn't like the licenses of the existing libraries. 
I could go on but your question shows a real lack of imagination.

> Numerous generic packages for container types already exist--the
> original Booch components, the Ada 95 Booch components, the Ada
> Structured Library (my personal favorite), PragmAda, and so on.
> 
> I would much rather see an individual extend Ada's reach into new fields
> in which there's little or no Ada presence, rather than reworking the
> same, tired old ground.

Rather than telling other people what you'd rather they do, why don't
you just go do it yourself? If someone wants to create another container 
library in Ada I say "more power to'em!". That ground doesn't look old and
tired to me. 

Libertarianly, 

-- Brian

> Curmudgeonly,
> 
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> 

Re: Containers with Ada

[Wolfgang Jeltsch]

> If List contains "thousands of elements", I suspect it's probably not
> an elementary type [Ada Reference Manual 3.2:3]. (It may _reference_
> them, but then only the reference is being passed, not the elements).
> Therefore, it doesn't have to be passed by copy [ARM 6.2:3], and most
> compilers won't.
I thought that every type which is not a by-reference type is a by copy
type. Thank you for the correction.

> Similar rules apply to the returned value.
As far as I can see from [ARM 6.5] a type must be limited to be a
return-by-reference type.

> It may be a good idea to declare List a limited type, but not for
> reasons of controlling the passing convention.
For what reasons it would be good?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Wolfgang Jeltsch]

> There's nothing in the standard that requires this for the _exact_
> example you post, AFAIK. If you really think you're seeing this, you
> may want to contact GNAT. Note that replacing "Length : Natural" with
> "Length : Natural := 0" will cause the behavior you describe, as well
> as a potential GNAT message - "warning: creation of object of this
> type may raise Storage_Error.". That _is_ consistent with the
> standard.
Sorry, I didn't remember that the problems with memory consumption I had
arose when I used a default value for Length. In my original List
implementation this was needed for growable lists:
   type Element_Array is array(Positive range <>);
   type Buffer(Size : Natural := Init_Size) is record
      Elements : Element_Array(1 .. Size);
   end record;
   type Growable_List is record
      Element_Buffer : Buffer;
      Real_Size      : Natural :=0;
   end record;
This example is not possible with GNAT why I have to use references to
the buffer why Growable_List must be a controlled type.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Wolfgang Jeltsch]

> Simply define the types and instantiations you need at the
> library level, and parametrize them appropriately.
What do you mean with "parametrize them appropriately"?

> You are making the mistake of having a preconceived idea
> of how to do things, and unfortunately the idea is wrong.
> Try describing what you want to do at a high level, rather
> than providing solutions that are wrong and complaining
> about the solutions not working.
I simply want to have some list packages I can use nearly everywhere
where I need a list. I don't want to have packages for a concrete idea
but packages that are universal.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Wolfgang Jeltsch]

> Numerous generic packages for container types already exist--the
> original Booch components, the Ada 95 Booch components, the Ada
> Structured Library (my personal favorite), PragmAda, and so on.
Are any of them open source? If this is the case from where can I
download them? It would be interesting for me to see how they have
solved the "container problems".

> I would much rather see an individual extend Ada's reach into new
> fields in which there's little or no Ada presence, rather than
> reworking the same, tired old ground.
What fields do you think of?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Containers with Ada

[Brian Rogoff]

On 20 Nov 2000, Stephen Leake wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > <snip>
> > 
> > Rather than telling other people what you'd rather they do, why
> > don't you just go do it yourself? If someone wants to create another
> > container library in Ada I say "more power to'em!". That ground
> > doesn't look old and tired to me.
> 
> Someone looking to create an Ada library should make an attempt to
> find out what's already been done. 

Obviously. Look at the first two sentences you snipped:

>> Maybe he doesn't like what's already out there, and thinks he can do
>> better. Maybe he doesn't like the licenses of the existing libraries. 

Now, jeltsch has posted a few more times and it's clear he hasn't looked 
at www.adapower.com (thank you David Botton, you are awesome!) to see what
else is available but I couldn't tell from the first post. 

> Then they can either just use it, or improve on it, 

If the license permits...

> or start from scratch. In any case, we'll all learn
> something (if they tell us :).

Yes, unfortunately it is hard to get useful feedback. 

So, how is SAL going? ;-)

-- Brian

Re: Containers with Ada

[Stephen Leake]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> <snip>
> 
> Rather than telling other people what you'd rather they do, why
> don't you just go do it yourself? If someone wants to create another
> container library in Ada I say "more power to'em!". That ground
> doesn't look old and tired to me.

Someone looking to create an Ada library should make an attempt to
find out what's already been done. Then they can either just use it,
or improve on it, or start from scratch. In any case, we'll all learn
something (if they tell us :).

-- 
-- Stephe

Re: Containers with Ada

[Brian Rogoff]

On Sun, 19 Nov 2000, Robert Dewar wrote:
> It is by the way a definite limitation in Ada 95 that some
> facilities of the language do not extend fully to nested
> subprograms (though not quite as much a limitation as not
> having nested subprograms at all, as in C or C++ :-)

I guess for my tastes these restrictions one inherits from the use of 
controlled types with respect to nested subprograms makes their use 
for container libraries problematic. I use nested subprograms a lot, even 
in a low level language like Ada. ("Low level" is not used in a pejorative 
sense here :).

Obviously the restrictions with respect to access to subprogram are
bothersome too but if that irritates me I just use another language. 

-- Brian

Re: Containers with Ada

[Marc A. Criley]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> <snip>
>
> Rather than telling other people what you'd rather they do, why
> don't you just go do it yourself?

Uhhh..I do.  I'm also happy to assist anyone who may need some Ada
advice pertaining to whatever it is they may be working on, whether in
this forum, gnatlist, or gnat chat (if that somehow gets reformulated
back into a public forum).

> If someone wants to create another
> container library in Ada I say "more power to'em!". That ground
> doesn't look old and tired to me.

I guess the problem is that having worked with Ada for over 15 years, I
can write container packages in my sleep, but I don't bother since
there's a score of variations to pick from.  If someone's undertaking
such an effort to aid their learning of Ada, then yes, "more power to
them!"  But otherwise, do something new!

I've been working a lot with ASIS (Ada Semantic Information
Specification) lately, and if one wants to stay within pure Ada, and is
interested in developing development and analysis tools, aids for doing
ASIS development would be incredibly welcome.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation

Re: Containers with Ada

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> Brian Rogoff <bpr@shell5.ba.best.com> writes:
>
> > <snip>
> >
> > Rather than telling other people what you'd rather they do, why
> > don't you just go do it yourself? If someone wants to create another
> > container library in Ada I say "more power to'em!". That ground
> > doesn't look old and tired to me.
>
> Someone looking to create an Ada library should make an attempt to
> find out what's already been done. Then they can either just use it,
> or improve on it, or start from scratch. In any case, we'll all learn
> something (if they tell us :).

There are other factors that must be considered before using an
EXISTING package:

  1. -  Who controls its design and interface?
  2. -  Is it likely to undergo changes in the future?
  3. -  How stable are the various existing releases of this package out there?

If I write an application for donation to the Open Source movement,
these are often deciding factors for me. For example, if I write an
application based upon the florist package, and the package specs
change, then people who try to compile my application are going to
whine to me that it doesn't compile. (Actually, the specs need not change--
for example there can be unresolved links in the library etc. leading to
other build problems).

Many users out there that barely can manage a make command, don't
recognize where the problem lies. Consequently, if I suspect that this
will be a problem, I'll create my own interfaces that are NOT subject
to change (or implementation problems).

Even if issues 1 and 2 are resolved, #3 can be a problem. For example
if there are many distributions out there with busted florist libraries installed,
then I have to either:

   a)  include comprehensive instructions to the user to identify and upgrade
        the offending packages/libraries..
   b)  or insulate my application from these problems, to avoid whining
        emails.

Often, I'll choose "b" because my time is too short to help all the users work
out issue "a".

CONCLUSION:

Consequently, only if a package and most of it's existing versions are stable
and working, will I consider it for an open source project. For internal projects,
this is not really an issue (I can just grumble when it needs adjustment, but then
I only need to fix it once -- not for every other user out there).

> --
> -- Stephe

POSTSCRIPT:

This is the reason I think it is VERY IMPORTANT that standards be developed
for re-usable components. Once the standard is announced, the developer has
some sort of assurance about the interfaces involved, today, and into the future.

Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Containers with Ada

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > Stephen Leake wrote:
> >
> > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> ...snip...

> > > Someone looking to create an Ada library should make an attempt to
> > > find out what's already been done. Then they can either just use it,
> > > or improve on it, or start from scratch. In any case, we'll all learn
> > > something (if they tell us :).
> >
> > There are other factors that must be considered before using an
> > EXISTING package:
> >
> >   1. -  Who controls its design and interface?
> >   2. -  Is it likely to undergo changes in the future?
> >   3. -  How stable are the various existing releases of this package out there?
>
> All good points.
>
> >   <snip discussion of various solutions>
>
> Perhaps a better solution for open source packages is to distribute
> exactly the version you test with (which you may have patched), with
> the caveat that users who use other versions are on their own.

Certainly, that is one solution. For large packages like florist however,
distributing that with a small application goes against the grain, especially
for the user who downloads with 56k modems.

> That's one of the beauties of open source; you can insulate yourself
> from all the maintenance issues just by distributing the version of
> the source you happened to use.

Yes, with the above disadvantage noted.  Sometimes, it is possible just
to extract the pieces you need. However, that is not always easy, or even
advisable.

> I would hope you would make an effort to contribute fixes and upgrade
> to later versions, but there's really no need to require your users to
> do that on their own!
>
> --
> -- Stephe

You don't specifically indicate what I should perform "fixes and upgrade
to later versions" for, but I'll assume that you mean my own contributed
applications. If so, then yes indeed. However, some balance is required
here however.

My goal for written applications, is to be the "May Tag repair man". I want to
be able to move onto _NEW_ projects, since time is a limited resource.  If I
must keep revisiting an application that does not need enhancing, just to
make it compile and work again, I get rather annoyed (when the change is
seemingly unnecessary).

It's an imperfect world, so I accept the reality that changes are sometimes
required. But IMHO, it should be possible most of the time to build applications
without making a career out of it ;-)

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Containers with Ada

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Stephen Leake wrote:
> 
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> >
> > > <snip>
> > >
> > > Rather than telling other people what you'd rather they do, why
> > > don't you just go do it yourself? If someone wants to create another
> > > container library in Ada I say "more power to'em!". That ground
> > > doesn't look old and tired to me.
> >
> > Someone looking to create an Ada library should make an attempt to
> > find out what's already been done. Then they can either just use it,
> > or improve on it, or start from scratch. In any case, we'll all learn
> > something (if they tell us :).
> 
> There are other factors that must be considered before using an
> EXISTING package:
> 
>   1. -  Who controls its design and interface?
>   2. -  Is it likely to undergo changes in the future?
>   3. -  How stable are the various existing releases of this package out there?

All good points.

>   <snip discussion of various solutions>

Perhaps a better solution for open source packages is to distribute
exactly the version you test with (which you may have patched), with
the caveat that users who use other versions are on their own.

That's one of the beauties of open source; you can insulate yourself
from all the maintenance issues just by distributing the version of
the source you happened to use. 

I would hope you would make an effort to contribute fixes and upgrade
to later versions, but there's really no need to require your users to
do that on their own!

-- 
-- Stephe

Re: Containers with Ada

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> <snip>
> > Perhaps a better solution for open source packages is to distribute
> > exactly the version you test with (which you may have patched), with
> > the caveat that users who use other versions are on their own.
> 
> Certainly, that is one solution. For large packages like florist however,
> distributing that with a small application goes against the grain, especially
> for the user who downloads with 56k modems.

Hmm. If they have the same version, they don't have to download your
copy. If they don't, they can either try it with a different version,
or download your copy. I don't see how they are worse of than if you
did not provide a copy. Ah, maybe you thought I meant the packages
should be bundled in your zip file; probably not.

> <snip>
> > I would hope you would make an effort to contribute fixes and upgrade
> > to later versions, but there's really no need to require your users to
> > do that on their own!
> 
> You don't specifically indicate what I should perform "fixes and upgrade
> to later versions" for, but I'll assume that you mean my own contributed
> applications.

Sorry, I wasn't very clear. For example, if you distribute an app that
works with Florist 1.1, but breaks with Florist 1.2, you should either
upgrade your app to work with Florist 1.2, or fix Florist 1.2,
whichever seems more appropriate.

> My goal for written applications, is to be the "May Tag repair man". I want to
> be able to move onto _NEW_ projects, since time is a limited resource.  If I
> must keep revisiting an application that does not need enhancing, just to
> make it compile and work again, I get rather annoyed (when the change is
> seemingly unnecessary).
> 
> It's an imperfect world, so I accept the reality that changes are sometimes
> required. But IMHO, it should be possible most of the time to build applications
> without making a career out of it ;-)

Yes, I totally agree. I'm working on Windex (a binding to Win32), and
for now I feel free to change the user API, because I know it's pretty
far from right. But at some point, it has to freeze, and just live
with any imperfections.

-- 
-- Stephe

Re: Containers with Ada

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> > <snip>
> > > I would hope you would make an effort to contribute fixes and upgrade
> > > to later versions, but there's really no need to require your users to
> > > do that on their own!
> >
> > You don't specifically indicate what I should perform "fixes and upgrade
> > to later versions" for, but I'll assume that you mean my own contributed
> > applications.
>
> Sorry, I wasn't very clear. For example, if you distribute an app that
> works with Florist 1.1, but breaks with Florist 1.2, you should either
> upgrade your app to work with Florist 1.2, or fix Florist 1.2,
> whichever seems more appropriate.

The former is usually the simplest (which is what my normal response
is).  This leads to a quick solution to the user's email request.

The later case usually requires that you contact
the author of the offending package, and hope that he'll accept your patches.
Then, you must *wait* for it to be released. This process does not help
the poor user who has contacted you with a message saying
"your software won't compile". The emailing user often has no
appreciation for the fact that it _did_ compile with the
original components used.

Another alternative is to make patches to Florist 1.2 available to address
the issue, but this requires the poor user to apply, compile and install
them successfully. Many users are not up to this task.  Not only that,
it requires you to revisit this issue again when Florist 1.3 comes out
(assuming that your feedback to the Florist maintainers has not been
accepted, or taken to heart, or simply still "in the queue").

[NOTE: I am not picking on Florist here-- only using it as an example]

Even when cvs access to the package is available, and even if your changes
are adopted (they might be overruled), you then still must get the end user to
download those "improved sources" and recompile and install them himself.
This is fraut with more frustrated end users, and thus, more emails in my
inbox ;-)

Anyway, I am just re-stating my original statement here -- standards are
necessary to prevent most of this tussle.  If there is too much perceived
"hassle factor" to use an existing package, I won't use it. If it is small, or
if the components extractable from a larger package, then I'll include them
in with my sources, so that I can _insulate_ myself from those changes.

It would be nice to see more _STANDARDIZED_ packages available.
As I posted earlier, standards give the application writer confidence about
the future of the API and it's behaviour.

> > My goal for written applications, is to be the "May Tag repair man". I want to
> > be able to move onto _NEW_ projects, since time is a limited resource.  If I
> > must keep revisiting an application that does not need enhancing, just to
> > make it compile and work again, I get rather annoyed (when the change is
> > seemingly unnecessary).
> >
> > It's an imperfect world, so I accept the reality that changes are sometimes
> > required. But IMHO, it should be possible most of the time to build applications
> > without making a career out of it ;-)
>
> Yes, I totally agree. I'm working on Windex (a binding to Win32), and
> for now I feel free to change the user API, because I know it's pretty
> far from right. But at some point, it has to freeze, and just live
> with any imperfections.
>
> --
> -- Stephe

Certainly, anything that is truly "in development" has to have the caveat that
the API is subject to change. This is OK, since it allows others to take
advantage of the same work, while it is progressing. Others can contribute
(hopefully constructive) criticism, and patches.

All I am saying is that using existing packages in a state of "flux"
is often more aggrivation than it is worth, considering the long run.

Some people like to continue to enhance and build upon various open source
projects, and this is necessary for large projects.  I myself, have many interests,
including building solutions to new problems. As you agreed, we
don't like to revisit the same old stuff unnecessarily.

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Containers with Ada (distribution of)

[Warren W. Gay VE3WWG]

I neglected to answer one other point, in my previous post..

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > <snip>
> > > Perhaps a better solution for open source packages is to distribute
> > > exactly the version you test with (which you may have patched), with
> > > the caveat that users who use other versions are on their own.
> >
> > Certainly, that is one solution. For large packages like florist however,
> > distributing that with a small application goes against the grain, especially
> > for the user who downloads with 56k modems.
>
> Hmm. If they have the same version, they don't have to download your
> copy. If they don't, they can either try it with a different version,
> or download your copy. I don't see how they are worse of than if you
> did not provide a copy. Ah, maybe you thought I meant the packages
> should be bundled in your zip file; probably not.

I had assumed you meant the latter, but no matter...

It is true that you can make copies of an original "package" available on
your own web site (separate from your application's tarball/rpm). However,
this doesn't help with the sunsite.unc.edu ftp site etc. They (like many other
ftp sites), only keep the most recent versions of submitted packages.

IMHO, this is just one more hassle to deal with.  I can barely find the
time and inclination to keep my web site up to date as it is ;-)

> -- Stephen

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Does anyone use Anna?

[Lao Xiao Hai]

JF Harrison wrote:

> Hi,
>   While searching through Amazon.com I found the following text: "Anna : A
> Language for Annotating Ada Programs : A Reference Manual (Lecture Notes in
> Computer Science, Vol 260)" by David Luckham.  Is this used much in the
> industry?  If not, does it look like it will be?
>
> Regards,
> JF Harrison

The Center for Reliable Computing at Stanford University had some researchers,
Doug Bryan and Geoff Mendal, working on ANNA.   Both have left the Ada community

and there seems to be no effort currently in place.  I don't think ANNA has ever
been
updated to correspond to Ada 95.  This would make a really good research project

for someone if there were any possibility of getting it funded.

Richard Riehle


>
> From the book description at
> http://www.amazon.com/exec/obidos/ASIN/0387179801/qid=975111777/sr=1-4/104-1
> 905124-4917565
>
> "ANNA is a language extension of ADA to include facilities for formally
> specifying the intended behavior of ADA programs. It is designed to meet a
> perceived need to augment ADA with precise machine-processable annotations
> so that well established formal methods of specification and documentation
> can be applied to ADA programs. The current ANNA design includes annotations
> of all ADA constructs except tasking. Similar extensions for formal
> specification can be made to other Algol-like languages such as Pascal,
> PL/1, Concurrent Pascal, and Modula; essentially, these extensions would be
> subsets of ANNA. The design of ANNA was undertaken from the beginning with
> four principal considerations: 1. Constructing annotations should be easy
> for the ADA programmer and should depend as much as possible on notation and
> concepts of ADA. 2. ANNA should possess language features that are widely
> used in the specification and documentation of programs. 3. ANNA should
> provide a framework within which the various established theories of
> formally specifying programs may be applied to ADA. 4. Annotations should be
> equally well suited for different possible applications during the life
> cycle of a program. Such applications include not only testing, debugging
> and formal verification of a finished program, but also specification of
> program parts during the earlier stages of requirements analysis and program
> design."