worth the hassle?

worth the hassle?

[chris.danx]

Hi,

Been working on Aqua for a wee while now, but the code for the list exposes
my misunderstanding of iterators so I'm re-writing it and it should be out
on Thursday (touch wood).

Since the list had to be rewritten, it seemed like a good time to
re-evaluate one of the design decisions concerning the types permittable at
instantiation of the list (and other types).  I never use limited types, and
didn't code any support for them into the first list implementation.  This
bugged me a little but since limited types require an assignment operation
to allow the list to function seemed a little bit inconvienant for the user.

Is this a worth while tradeoff?  I guess the question "how often are limited
types used?" would serve better, as it would give a measure on which to base
a decision.


Chris

Re: worth the hassle?

[Wes Groleau]

Was this supposed to be on a Mac OS X list?

"chris.danx" wrote:
> 
> Hi,
> 
> Been working on Aqua for a wee while now, but the code for the list exposes

[snip]

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: worth the hassle?

[chris.danx]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3D3C3E1B.914CDCD8@despammed.com...
>
> Was this supposed to be on a Mac OS X list?

Nope, Aqua is an ADT library.  Why?  What is Aqua in Mac OS X terms?


Chris

p.s. in the first post, the hassle is not in coding the ADT, it's the hassle
to the ADT user(the implementing of assign (a, to_b) for every type, even
simple ones like integer).

Re: worth the hassle?

[Wes Groleau]

"chris.danx" wrote:
> > Was this supposed to be on a Mac OS X list?
> 
> Nope, Aqua is an ADT library.  Why?  What is Aqua in Mac OS X terms?

I see.  It's also the name of Mac's GUI
(X11-like, but only single-user)

There are folks currently working
on or with Ada bindings for it, so
I thought you might have been one
of those and misdirected the post.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: worth the hassle?

[chris.danx]

hmm, problem...


This is the top of the unbounded doubly linked list.

generic
   type Element_Type is limited private;
   type List_Id_Type is private;

   -- Assign A to B.
   --
   with procedure Assign (A : in     Element_Type;
                          B : in out Element_Type) is <>;

package Aqua.Lists.Linear.Unbounded.Doubly is
...
end Aqua.Lists.Linear.Unbounded.Doubly;


Let's say we have 2 types (a_type & b_type) derived from a single type,
base_type and we want to store objects of all three types in the *same
list*.  How do we code assign for this situation?  What happens if the
derved classes are not known before hand?  Is it even possible to put the
all the types in the same list?


Cheers,
Chris

Re: worth the hassle?

[Stephen Leake]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> hmm, problem...
> <snip code>
> 
> Let's say we have 2 types (a_type & b_type) derived from a single type,
> base_type and we want to store objects of all three types in the *same
> list*.  How do we code assign for this situation?  What happens if the
> derved classes are not known before hand?  Is it even possible to put the
> all the types in the same list?

Use a class-wide access type in the list:

type Element_Access is access all Element_Type'class;

To mangle someone else's quote: "there is almost no problem in
computer science that a layer of indirection won't solve".

-- 
-- Stephe

Re: worth the hassle?

[chris.danx]

Thanks, it's much appreciated!

Anyone up for another problem? :)

An iterator points to a list and a position within in that list.  The
problem is getting a pointer to the list itself, which is an "in" parameter
(it's not modified) to a function.

What is a good way of getting the pointer to the list?  'access doesn't work
since list is constant, and I don't want to make the parameter an access
type since it's not convienant to declare lists as aliased all the time.


Sorry for asking so many questions,
Chris

Re: worth the hassle?

[chris.danx]

Is using address_to_access_conversions the correct solution?  Something
along the lines of

package List_Address_Conversions
      is new System.Address_To_Access_Conversions (List_Type);

function First (List : in List_Type) return Iterator_Type is
begin
   ...
   return Iterator_Type'(List_Address_Conversions.to_pointer(List'Address),
List.First);
end First;

?

Re: worth the hassle?

[chris.danx]

Fixed it with the help of the Booch components.

function First (List : in List_Type) return Iterator_Type is
begin
   if Is_Empty (List) then
      raise Empty_List_Error;
   end if;
   return Iterator_Type'(
      List_Address_Conversions.To_Pointer(List'Address).all'access,
         List.First);
end First;

Re: worth the hassle?

[Stephen Leake]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> Thanks, it's much appreciated!
> 
> Anyone up for another problem? :)
> 
> An iterator points to a list and a position within in that list.  The
> problem is getting a pointer to the list itself, which is an "in" parameter
> (it's not modified) to a function.

This is the problem. There is no portable way to get an access value
to an "in" parameter.

If Ada seems to be in your way when you want to do something, it's for
a good reason!

> What is a good way of getting the pointer to the list? 'access
> doesn't work since list is constant, and I don't want to make the
> parameter an access type since it's not convienant to declare lists
> as aliased all the time.

You can take the approach I did in SAL; don't store a pointer to
the list in the iterators. That makes the iterators "unsafe", but more
efficient.

Or, you can take the approach that Grace.Lists does, and add a layer
of indirection in the List_Type; then you _can_ get an access value to
the list from an "in" parameter.

Unchecked programming is _not_ necessary.

-- 
-- Stephe

Re: worth the hassle?

[chris.danx]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ulm8232w7.fsf@gsfc.nasa.gov...

> If Ada seems to be in your way when you want to do something, it's for
> a good reason!
>
> > What is a good way of getting the pointer to the list? 'access
> > doesn't work since list is constant, and I don't want to make the
> > parameter an access type since it's not convienant to declare lists
> > as aliased all the time.
>
> You can take the approach I did in SAL; don't store a pointer to
> the list in the iterators. That makes the iterators "unsafe", but more
> efficient.

They must be safe, so that approach isn't appropriate

> Or, you can take the approach that Grace.Lists does, and add a layer
> of indirection in the List_Type; then you _can_ get an access value to
> the list from an "in" parameter.

Do you mean something like

type a_list_type is ...

type list_type is record
   list : a_list_access;
end record;

or

type list_type is private;
...

private
   type a_list_type is ...

   type list_type is access a_list_type;

?

Where is the grace site?

Re: worth the hassle?

[chris.danx]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:Eqe%8.14162$rn5.1675139@news11-gui.server.ntli.net...

> > Or, you can take the approach that Grace.Lists does, and add a layer
> > of indirection in the List_Type; then you _can_ get an access value to
> > the list from an "in" parameter.

> [snip] like
>
> type a_list_type is ...
>
> type list_type is record
>    list : a_list_access;
> end record;

Looks like that one.

> Where is the grace site?

http://www.freesoftware.fsf.org/Grace/Grace_Home.html

Re: worth the hassle?

[Peter Hermann]

> http://www.freesoftware.fsf.org/Grace/Grace_Home.html

where I read the following:

"The Grace Ada Compoent Library
                                 Last Update - 4/18/2002"

1. A headline in boldface with a typo may not be inviting.
2. Date indicates "no activity".

Re: worth the hassle?

[chris.danx]

"Peter Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message
news:ahjvmu$v4g$1@news.uni-stuttgart.de...
> > http://www.freesoftware.fsf.org/Grace/Grace_Home.html
>
> where I read the following:
>
> "The Grace Ada Compoent Library
>                                  Last Update - 4/18/2002"
>
> 1. A headline in boldface with a typo may not be inviting.
> 2. Date indicates "no activity".

Same for Nick Roberts ASCL

Re: worth the hassle?

[Stephen Leake]

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> writes:

> > http://www.freesoftware.fsf.org/Grace/Grace_Home.html
> 
> where I read the following:
> 
> "The Grace Ada Compoent Library
>                                  Last Update - 4/18/2002"
> 
> 1. A headline in boldface with a typo may not be inviting.
> 2. Date indicates "no activity".

Both are good points.

1. Submit a bug report on the site for the typo :).

2. Submit some good code :)

-- 
-- Stephe

Re: worth the hassle?

[Stephen Leake]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> <snip discussion of lists supporting limited types>
 
> Is this a worth while tradeoff?  I guess the question "how often are limited
> types used?" would serve better, as it would give a measure on which to base
> a decision.

This was discussed extensively back in December 2001 during the Grace
Lists requirements development. You could search on Google for that
discussion.

My own opinion is that supporting limited types is a requirement for
any general-purpose container.

This is probably one reason why Ada will never be as popular as C++;
in C++, you don't have to make this kind of decision :).

-- 
-- Stephe

Re: worth the hassle?

[Frank J. Lhota]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uheirlk4z.fsf@gsfc.nasa.gov...
> My own opinion is that supporting limited types is a requirement for
> any general-purpose container.
>
> This is probably one reason why Ada will never be as popular as C++;
> in C++, you don't have to make this kind of decision :).

Why isn't this a C++ issue as well? Certainly it is possible to declare the
C++ equivalent of a limited type, i.e. a type for which assignment is not
available.

Re: worth the hassle?

[Stephen Leake]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:uheirlk4z.fsf@gsfc.nasa.gov...
> > My own opinion is that supporting limited types is a requirement for
> > any general-purpose container.
> >
> > This is probably one reason why Ada will never be as popular as C++;
> > in C++, you don't have to make this kind of decision :).
> 
> Why isn't this a C++ issue as well? Certainly it is possible to declare the
> C++ equivalent of a limited type, i.e. a type for which assignment is not
> available.

True, you can hide the copy operator by declaring it private. But the
template declaration does not declare whether you should/can do that,
so the decision is not obvious. You'll get link errors if your client
class does not have the required methods.

There _is_ a smiley there!

-- 
-- Stephe

Re: worth the hassle?

[Kevin Cline]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<RYX_8.20976$927.2872@nwrddc01.gnilink.net>...
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:uheirlk4z.fsf@gsfc.nasa.gov...
> > My own opinion is that supporting limited types is a requirement for
> > any general-purpose container.
> >
> > This is probably one reason why Ada will never be as popular as C++;
> > in C++, you don't have to make this kind of decision :).
> 
> Why isn't this a C++ issue as well? Certainly it is possible to declare the
> C++ equivalent of a limited type, i.e. a type for which assignment is not
> available.

It is a C++ issue, but it is now fairly standard practice to write
containers that only require the contained class to have a copy constructor.
The STL is implemented in this way.  The containers allocate raw memory,
and use placement-new and explicit destructor calls to create and
destroy objects, like this:

char* mem = new char[sizeof T];  // get some memory
T* t = new T(mem, *oldT); // copy-construct object on mem
t->~T();                  // destroy object

Not the sort of thing one would want to see sprinkled through
an application, but fine if encapsulated in a container class.

Re: worth the hassle?

[chris.danx]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uheirlk4z.fsf@gsfc.nasa.gov...
> This was discussed extensively back in December 2001 during the Grace
> Lists requirements development. You could search on Google for that
> discussion.

side note: What's happening with Grace?

I checked Nick Roberts summary for ASCL/Grace and that was no use, I'll dig
into the archives of the discussion if I get time and see what the detailed
arguments were.

> My own opinion is that supporting limited types is a requirement for
> any general-purpose container.

I am in two minds.  One says forget limited just now and later on code a set
of limited equivalents later.  The code will be simple enough that copying
and modifying the non-limited packages should be no problem.  The other says
just use limted types, after all it's only one routine and it's not so
inconvienant.

Grrrr..... :(

Convienance says non-limited so maybe that's the way it will go.


Chris

Re: worth the hassle?

[Kevin Cline]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uheirlk4z.fsf@gsfc.nasa.gov>...
> "chris.danx" <spamoff.danx@ntlworld.com> writes:
> 
> > <snip discussion of lists supporting limited types>
>  
> > Is this a worth while tradeoff?  I guess the question "how often are limited
> > types used?" would serve better, as it would give a measure on which to base
> > a decision.
> 
> This was discussed extensively back in December 2001 during the Grace
> Lists requirements development. You could search on Google for that
> discussion.
> 
> My own opinion is that supporting limited types is a requirement for
> any general-purpose container.
> 
> This is probably one reason why Ada will never be as popular as C++;
> in C++, you don't have to make this kind of decision :).

That's right -- in C++ there is no distinction between classes
with user-defined constructors and destructors and classes without
them.  This is another factor that makes generic programming
easier in C++ than it is in Ada.

I think the decision in Ada to create a distinction between
'limited' and ordinary types was a mistake.  It gives programmers
the impression that 'limited types' are somehow exotic, but IMHO
almost all user-defined types should be limited types.

Re: worth the hassle?

[Stephen Leake]

kcline17@hotmail.com (Kevin Cline) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:<uheirlk4z.fsf@gsfc.nasa.gov>... 
> > "chris.danx" <spamoff.danx@ntlworld.com> writes:
> > 
> > > <snip discussion of lists supporting limited types>
> >  
> > > Is this a worth while tradeoff?  I guess the question "how often
> > > are limited 
> > > types used?" would serve better, as it would give a measure on
> > > which to base 
> > > a decision.
> > 
> > This was discussed extensively back in December 2001 during the Grace
> > Lists requirements development. You could search on Google for that
> > discussion.
> > 
> > My own opinion is that supporting limited types is a requirement for
> > any general-purpose container.
> > 
> > This is probably one reason why Ada will never be as popular as C++;
> > in C++, you don't have to make this kind of decision :).
> 
> That's right -- in C++ there is no distinction between classes
> with user-defined constructors and destructors and classes without
> them.  This is another factor that makes generic programming
> easier in C++ than it is in Ada.

It may be "easier" to write a template for a container class, but it
is _not_ easier to use. If I happen to have a class that has a hidden
copy operator, I'll get some obscure link time error when I try to
instatiate a container that requires a copy operator.

I'd much rather have that kind of error show up at compile time.

> I think the decision in Ada to create a distinction between
> 'limited' and ordinary types was a mistake. It gives programmers the
> impression that 'limited types' are somehow exotic, but IMHO almost
> all user-defined types should be limited types.

Hmm. Just because the term "limited" appears in Ada, but no other
language (that I know of), makes it "exotic"? Well, I guess that might
be true for some newbies. But if it is presented correctly, it's just
a reasonable way to define types.

Since you think "almost all user-defined types should be limited
types", perhaps you would prefer that the default type in Ada be
"limited", and a non-limited type require an extra keyword, perhaps
"assignable"? That would be interesting, but not upward compatible
with Ada 83, since Standard.Integer etc don't have the keyword
"assignable". 

-- 
-- Stephe

Perhaps we keep lists elements private and adjust the elements to fit?

[Chad R. Meiners]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uheirlk4z.fsf@gsfc.nasa.gov...
> "chris.danx" <spamoff.danx@ntlworld.com> writes:
>
> > <snip discussion of lists supporting limited types>
>
> > Is this a worth while tradeoff?  I guess the question "how often are
limited
> > types used?" would serve better, as it would give a measure on which to
base
> > a decision.
>
> This was discussed extensively back in December 2001 during the Grace
> Lists requirements development. You could search on Google for that
> discussion.
>
> My own opinion is that supporting limited types is a requirement for
> any general-purpose container.

Perhaps what we need to do is write the container libraries to accept
private types and provide a generic package that converts limited privates
to private types.  Let's assume that we have a limited type as follows

package Mylim is

   type Mine is limited private;

   procedure Copy(Item : in Mine; Object : out Mine);

private

   type Mine is new Integer;

end Mylim;

package body Mylim is

   procedure Copy(Item : in Mine; Object : out Mine) is
   begin
      Object := Item;
   end Copy;

end Mylim;

We want to use this type in a container package(that only accepts private
types), but we don't want to convert the package to use a private type.
Instead ,we can use a generic wrapper to convert the type for use with our
favorite container package.  I very simple wrapper (in other words untested
but it does compile) would look like

with Ada.Finalization;

generic
   type Limited_Type is limited private;
   with procedure Copy(Item : in Limited_Type; Object : out Limited_Type);
package Promote is

  type Storage is private;

  function  To    (Item : in Limited_Type) return Storage;
  procedure From  (Item : in Storage; Becomes : out Limited_Type);

private

   Default_Limited_Type : Limited_Type;

   type Limited_Access is access Limited_Type;

   type Storage is new Ada.Finalization.Controlled with
      record
         Item : Limited_Access;
      end record;

   procedure Initialize(Object : in out Storage);
   procedure Adjust    (Object : in out Storage);
   procedure Finalize  (Object : in out Storage);


end Promote;

with Ada.Unchecked_Deallocation;
package body Promote is

   ------------
   -- Adjust --
   ------------

   procedure Adjust (Object : in out Storage) is

   begin
      if Object.Item /= null then
         declare
            Temp : Limited_Access := new Limited_Type;
         begin
            Copy (Object.Item.all,Temp.all);
            Object.Item := Temp;
         end;
      end if;
   end Adjust;

   --------------
   -- Finalize --
   --------------

   procedure Finalize (Object : in out Storage) is

      procedure Free is new Ada.Unchecked_Deallocation(Limited_Type,
                                                       Limited_Access
                                                      );

   begin

      Free (Object.Item);

   end Finalize;

   ----------
   -- From --
   ----------

   procedure From  (Item : in Storage; Becomes : out Limited_Type) is
   begin
      if Item.Item = null then
         Copy (Default_Limited_Type, Becomes);
      else
         Copy (Item.Item.all, Becomes);
      end if;
   end From;

   ----------------
   -- Initialize --
   ----------------

   procedure Initialize (Object : in out Storage) is
   begin
      null;
   end Initialize;

   --------
   -- To --
   --------

   function To (Item : in Limited_Type) return Storage is
      Temp : Storage;
   begin
      Temp.Item := new Limited_Type;
      Copy (Item, Temp.Item.all);

      return Temp;
   end To;

end Promote;

so we can then promote Mylim.Mine to the status of private type with the
following package.

with Promote;
package Mylim.Storage is new Promote(Mylim.Mine,MyLim.Copy);

This schema has the advantage that container libraries can be written to
take private types which simplifies their use to the newbie since they can
easily instantiate linked lists of integers without having to write a copy
procedure for them.  Once someone has become conformable with using limited
types they should also be comfortable with performing a type promotion.
Comments, anyone?

-Chad R. Meiners

Re: Perhaps we keep lists elements private and adjust the elements to fit?

[Stephen Leake]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:uheirlk4z.fsf@gsfc.nasa.gov...
> > My own opinion is that supporting limited types is a requirement for
> > any general-purpose container.
> 
> Perhaps what we need to do is write the container libraries to accept
> private types and provide a generic package that converts limited privates
> to private types.  Let's assume that we have a limited type as follows

> <snip interesting proposal for wrapper package>

"Promoting" a limited type to a private type by adding a generic
"copy" operation is certainly one way to go. 

In SAL, I allowed for "true" limited types, where copy makes no sense
in any situation. The container packages require a "Copy" operation,
but for "true" limited types, the user simply provide a "copy" that
raises an exception.

Also in SAL, I have helper packages that define the obvious "copy"
operation for a non-limited type.

I guess we could have a couple versions of the generic "promote"
package; one that does a simple copy, one that raises an exception.
Users could write others that do deep copy, etc. That might be better
than what I have in SAL now.

-- 
-- Stephe