List Container Straw Man (NJR V5R1)

List Container Straw Man (NJR V5R1)

[Nick Roberts]

I hope people have been having a look at my list container proposal at:

http://www.adaos.ukf.net

I've read some of the comments in the 'Queue' thread, which are encouraging.
Some thoughts do indeed occur:

(1) all the absolute (index-based) operations could go into a child package
SCL.Lists.[Unb|B]ounded.Absolute (allowing the Absolute_ prefixes to be
dropped);

(2) all the cursor declarations and cursor-based operations could go into a
child package SCL.Lists.[Unb|B]ounded.Cursors;

(3) instead of having numbered cursors inside the list object, it would be
possible to provide a separate cursor type, objects of which would be
attached to a specific list object by an Open procedure (and detached by a
Close).

Are these refinements attractive?

I shall ask David Botton if he would kindly host my proposals (and those of
anyone else who wishes) on www.adapower.com/labs or www.adapower.net (which
would be more appropriate?). Shall we stick with the project name 'ASCL' (at
least for the time being)?

All comments welcome!

I am willing to put in a fair bit of personal effort to developing a basic
set of containers (since they'll be so useful in AdaOS), including producing
documentation and sample implementations.

I think the recent discussion has proved that it would be far, far better
for the design to have input from a diverse set of Ada users than to be a
product of just my own mind, floating about as it does in a little world of
its own most of the time.

--
Best wishes,
Nick Roberts

Re: List Container Straw Man (NJR V5R1)

[Nick Roberts]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9u6ahm$6gdc1$1@ID-25716.news.dfncis.de...

> (1) all the absolute (index-based) operations could go into a child
package
> SCL.Lists.[Unb|B]ounded.Absolute (allowing the Absolute_ prefixes to be
> dropped);
>
> (2) all the cursor declarations and cursor-based operations could go into
a
> child package SCL.Lists.[Unb|B]ounded.Cursors;

Inner packages rather than child packages (so they don't have to be
generic).

--
Best wishes,
Nick Roberts

Re: List Container Straw Man (NJR V5R1)

[Nick Roberts]

I've attempted to track the requirements:

http://www.adaos.ukf.net

I'll format them more neatly (maybe in a table) when I get time.

--
Best wishes,
Nick Roberts

Re: List Container Straw Man (NJR V5R1)

[Jeffrey Carter]

Nick Roberts wrote:
> 
> (2) all the cursor declarations and cursor-based operations could go into a
> child package SCL.Lists.[Unb|B]ounded.Cursors;

I think you have a serious misunderstanding of what a list is. The
operations based on positions are the basic operations of a list.
Anything else is just nice to have. Any component that lacks
position-based basic operations is not a list component.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: List Container Straw Man (NJR V5R1)

[Jeffrey Carter]

Note that my comments on 7

"[list elements must not be private] List elements must be limited
private."

are misleading, since they were made on the modified version

"List elements must not be limited private"

As to mimicking Ada.Strings.*, abstract strings are a special case of
unbounded arrays, not of lists, as they don't provide O(1) insertion and
deletion.

In order to be general, operations taking an array of elements would
have to be generic, so that the client may specify the array type. These
are easy enough for the client to implement with the basic operations,
so I doubt if they're worth the trouble of providing.

-- 
Jeffrey Carter

Re: List Container Straw Man (NJR V5R1)

[Nick Roberts]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3C07BCEB.86878310@boeing.com...
> Note that my comments on 7
>
> "[list elements must not be private] List elements must be limited
> private."
>
> are misleading, since they were made on the modified version
>
> "List elements must not be limited private"

Sorry. What, then, is your comment on the requirement:

List elements must be limited private.

please?

> As to mimicking Ada.Strings.*, abstract strings are a special case of
> unbounded arrays, not of lists, as they don't provide O(1) insertion and
> deletion.
>
> In order to be general, operations taking an array of elements would
> have to be generic, so that the client may specify the array type. These
> are easy enough for the client to implement with the basic operations,
> so I doubt if they're worth the trouble of providing.

I provided a specific array type, and corresponding insertion and
replacement operations, primarily for situations where it would be
particularly convenient for the programmer to construct an array aggregate.

Supposing one wanted to append a specific gene sequence (to concoct an
example) to a piece of DNA:

   Append( Seq_1, (Ad, Gu, Gu, Ad, Gu, Gu, Gu, Ad, Ad, Gu));

Doing this without the array type and operations would be less convenient,
possibly less readable, and probably less efficient.

An array of a different type (but with the same index and component types)
can be converted:

   type Gene_Array is (Positive range <>) of DNA_Gene_Marker;

   package Gene_Lists is new SCL.Lists.Unbounded(DNA_Gene_Marker);
   use Gene_Lists;

   ...

   Extra_1: constant Gene_Array :=
      (Ad, Gu, Gu, Ad, Gu, Gu, Gu, Ad, Ad, Gu);

   ...

   Append( Seq_1, Gene_Lists.Element_Array(Extra_1) );

Not pretty, but not too awful.

But certainly the array type and operations are only a convenience feature,
and could be removed without ruining the usefulness of the overall thing.

--
Best wishes,
Nick Roberts

Re: List Container Straw Man (NJR V5R1)

[Jeffrey Carter]

Nick Roberts wrote:
> 
> "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
> news:3C07BCEB.86878310@boeing.com...
> > Note that my comments on 7
> >
> > "[list elements must not be private] List elements must be limited
> > private."
> >
> > are misleading, since they were made on the modified version
> >
> > "List elements must not be limited private"
> 
> Sorry. What, then, is your comment on the requirement:
> 
> List elements must be limited private.
> 
> please?

Consensus: No
Me: Yes

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: List Container Straw Man (NJR V5R1)

[Nick Roberts]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C083C8C.2E4BCE58@acm.org...
> > Sorry. What, then, is your comment on the requirement:
> >
> > List elements must be limited private.
> >
> > please?
>
> Consensus: No
> Me: Yes

Done.

David Botton, splendid fellow, has set up a project on AdaPower.net:

http://www.adapower.net/ascl

which I hope will be the permanent home of this project now (and used by
everyone who wishes to participate, not just me!). Admin details yet to be
sorted out. More as and when.

--
Hang tough,
Nick Roberts

Re: List Container Straw Man (NJR V5R1)

[John English]

Nick Roberts wrote:
> 
> (3) instead of having numbered cursors inside the list object, it would be
> possible to provide a separate cursor type, objects of which would be
> attached to a specific list object by an Open procedure (and detached by a
> Close).

Why bother with Open and Close? Why not just operations like First(L)
(which returns an iterator pointing to the first element of list L)
to generate iterator/cursor values on demand? I'm not sure I see the
point of what you're proposing...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: List Container Straw Man (NJR V5R1)

[Nick Roberts]

"John English" <je@brighton.ac.uk> wrote in message
news:3C0E1B51.253F5E98@brighton.ac.uk...
> Nick Roberts wrote:
> >
> > (3) instead of having numbered cursors inside the list object, it would
be
> > possible to provide a separate cursor type, objects of which would be
> > attached to a specific list object by an Open procedure (and detached by
a
> > Close).
>
> Why bother with Open and Close? Why not just operations like First(L)
> (which returns an iterator pointing to the first element of list L)
> to generate iterator/cursor values on demand? I'm not sure I see the
> point of what you're proposing...

If a list has two (or more) cursors pointing into it at the same time, and
then an item is deleted (by one cursor) which affects the other(s) (because
the item was adjacent to it/them), the internal status of the other
cursor(s) must be adjusted appropriately.

If cursors are separate objects, it is therefore necessary not only: (a) for
each cursor to have a means of access to the list into which it points, but
also (b) for every list object to have a means of access to each of the
cursors that point into it.

The mechanism for (b) that I envisaged was a linked list (ironically). Which
means that before a cursor can be used to point into a list, there must be a
way to insert it into this linked list (e.g. Open), and, for efficiency and
bug-catching, there needs to be a way to remove it from the linked list
(e.g. Close).

Ramification: the list and cursor objects would both have to be declared
aliased by the user (yuk).

These complications make me doubt, in fact, that having separate cursor
objects would be any advantage.

There is a secondary point to make here. I have used the term 'cursor',
distinct from 'iterator', because I intend cursors to be: list specific;
bidirectional; randomly addressable. I intend to provide a further facility,
called iterators, which will be: container-wide; monodirectional; strictly
sequential. This is my terminology, no-one else's; apologies in advance for
any confusion.

--
Best wishes,
Nick Roberts