List container straw man (NJR V4)

List container straw man (NJR V4)

[Nick Roberts]

Text of message from me to Ted Dennison today:

===

After much revision, I think I'm getting nearer the 'sweet spot' you wanted
to hit: I've removed all trace of iteration from the base package (it'll be
in a child package), so you get your one-instantion-does-it; I've got rid of
the index-based operations, and put an 'offset' parameter in the
cursor-based ones (with a default of 0, so it can be ignored), which, with
the ability to specify an absolute base or a cursor base, obsoletes the
index-based operations (and adds cursor-based addressing); I've added
multiple cursors.

I've yet to finish the iterator packages and documentation; it may be the
weekend before these re done, but I think you'll like the results. In the
meantime, please the base and list packages (version 4). Post these on the
web site if you wish.

Thanks for your patience!

===

Please wait for the documentation before posting questions on this proposal.

--
Best wishes,
Nick Roberts

Re: List container straw man (NJR V4)

[Nick Roberts]

Okay, I've popped my own proposal on a web site:

http://www.adaos.ukf.net

with pointers to the rivals^H^H^H^H^H^Halternatives I'm aware of. Do please
pay a visit.

The SCL.Lists package should have been declared "pragma Preelaborate;", but
I forgot.

The inappropriate URL is not my fault. I hope to get a www.ascl.ukf.net
domain running soon.

--
Best wishes,
Nick Roberts

Re: List container straw man (NJR V4)

[Stephen Leake]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> Okay, I've popped my own proposal on a web site:
> 
> http://www.adaos.ukf.net

Excellent.

Please add a pointer to my proprosal:
http://users.erols.com/leakstan/Stephe/Ada/sal.html 

Also to PragmArc:
http://home.earthlink.net/~jrcarter010/pragmarc.htm

You might want to distinguish between more or less complete libraries
(all except yours and Ted's), and strawman proposals.

I suggest making the number of cursors a generic formal parameter,
with a default of 8.

The documentation does not discuss the rationale for using an abstract
base type. This is an important design decision; it should be clearly
justified (and I know it's important to you). 

I'm not clear which element this function returns:

function Element
   (Source : in Abstract_List;
    Base   : in Base_Designator := 1;
    Facing : in Direction       := Forward;
    Offset : in Integer         := 0)
   return Element_Type is abstract;

The doc says Base = 1 means cursor 1, and Offset = 0 means the
position "at" the cursor. But a cursor is between elements. So I think
you need to say "after the cursor, in direction specified by Facing".

This function can raise some exception if the cursor is null or after the
end of the list; the spec should say what exception.

I find the mixed meaning for Base too confusing (Base = 0 means Offset
is absolute, Base > 0 means offset is relative to that cursor). I'd
prefer two functions, one with a Cursor parameter, and one without. It
took me a while to figure out how to access an element via a cursor.
Then you can group the "cursor-oriented" subprograms together, and the
"index-oriented" subprogams together.

I also have a quibble; please consider formatting the code as above.
That's the format used in the RM, and in GNAT. There's a function in
Emacs Ada-mode that will do the alignment of the parameters
automatically. My stuff uses that format. Hmm, Ted isn't using that
format either. I can't find a multiline subprogram spec in PragmaArc,
so I don't know what style Jeff might prefer. Corey's style is close
to yours. Well, we can argue style later!

-- 
-- Stephe

Re: List container straw man (NJR V4)

[Jeffrey Carter]

Nick Roberts wrote:
> 
> Okay, I've popped my own proposal on a web site:
> 
> http://www.adaos.ukf.net
> 
> with pointers to the rivals^H^H^H^H^H^Halternatives I'm aware of. Do please
> pay a visit.

This is difficult to understand. This is the only place I've ever seen
the concept of "cursorage"; it is certainly not a standard list concept.
Combining the indexed operations and the cursor-based operations is
called control coupling and makes the operations difficult to
understand.

The use of undefined types is confusing. I suppose they're declared in
the parent package, but since we can't see the parent package it's still
confusing.

The use of an abstract type and operations followed by a non-abstract
extension and non-abstract operations doubles the size of the
specification without adding any value that I can see. Every concrete
list is going to have to declare and implement every operation, so
declaring them abstract an additional time seems like a waste of time.

Is_Empty and Length are basic list operations that are missing.

A component should not raise predefined exceptions such as
Constraint_Error. Use meaningful exceptions such as Cursor_Is_Null.

A concrete implementation should document the time complexity of every
operation, so the client can make appropriate choices of operations.
This argues against putting them in the private part. For an unbounded
list, the time complexity of the string- and dequeue-like operations
will be O(N), since they will have to do deep copies. The time
complexity of the indexed operations will be O(N), since they have to
count down the list. The cursor-based operations will tend to be O(1);
since they have the lowest time complexity they should be the preferred
operations and should therefore be presented first.

Each operation should document its pre- and post-conditions, where
applicable. Each operation should document what exceptions it may raise
and under what circumstances; since exceptions are generally indications
that the client has violated a precondition, the documentation for
preconditions is usually a good place to document exceptions.

With some more work this could be an acceptable standard specification.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: List container straw man (NJR V4)

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ug07drygb.fsf@gsfc.nasa.gov...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
>
> > Okay, I've popped my own proposal on a web site:
> >
> > http://www.adaos.ukf.net
>
> Excellent.
>
> Please add a pointer to my proprosal:
> http://users.erols.com/leakstan/Stephe/Ada/sal.html

Done!

> Also to PragmArc:
> http://home.earthlink.net/~jrcarter010/pragmarc.htm

Already there.

> You might want to distinguish between more or less complete libraries
> (all except yours and Ted's), and strawman proposals.

I'll go the other way, and not make any assertion about the completeness of
any of them.

> I suggest making the number of cursors a generic formal parameter,
> with a default of 8.

Agreed. Will do.

> The documentation does not discuss the rationale for using an abstract
> base type. This is an important design decision; it should be clearly
> justified (and I know it's important to you).

Will do.

> I'm not clear which element this function returns:
>
> function Element
>    (Source : in Abstract_List;
>     Base   : in Base_Designator := 1;
>     Facing : in Direction       := Forward;
>     Offset : in Integer         := 0)
>    return Element_Type is abstract;
>
> The doc says Base = 1 means cursor 1, and Offset = 0 means the
> position "at" the cursor. But a cursor is between elements. So I think
> you need to say "after the cursor, in direction specified by Facing".

That is correct. I will add this to the documentation.

> This function can raise some exception if the cursor is null or after the
> end of the list; the spec should say what exception.

Yes: a specific exception.

> I find the mixed meaning for Base too confusing (Base = 0 means Offset
> is absolute, Base > 0 means offset is relative to that cursor). I'd
> prefer two functions, one with a Cursor parameter, and one without. It
> took me a while to figure out how to access an element via a cursor.
> Then you can group the "cursor-oriented" subprograms together, and the
> "index-oriented" subprogams together.

This is exactly the design I had before 'merging' the two sets of
subprograms. I will undo this.

> I also have a quibble; please consider formatting the code as above.
> That's the format used in the RM, and in GNAT. There's a function in
> Emacs Ada-mode that will do the alignment of the parameters
> automatically. My stuff uses that format. Hmm, Ted isn't using that
> format either. I can't find a multiline subprogram spec in PragmaArc,
> so I don't know what style Jeff might prefer. Corey's style is close
> to yours. Well, we can argue style later!

I agree with you, and will format similar to the RM95.

--
Best wishes,
Nick Roberts

Re: List container straw man (NJR V4)

[Nick Roberts]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3BF6CCD6.F7195928@acm.org...
> ...
> This is difficult to understand. This is the only place I've ever seen
> the concept of "cursorage"; it is certainly not a standard list concept.
> Combining the indexed operations and the cursor-based operations is
> called control coupling and makes the operations difficult to
> understand.

The word 'cursorage' is my own Carrollean invention. Feel free to improve
upon it.

As for the combination of offset and cursor-basing, I shall undo this
combination, to produce separate sets of subprograms (as, in fact, I had
before).

> The use of undefined types is confusing. I suppose they're declared in
> the parent package, but since we can't see the parent package it's still
> confusing.

[Smacks forehead] Sorry! I'll put the base package into the picture.

> The use of an abstract type and operations followed by a non-abstract
> extension and non-abstract operations doubles the size of the
> specification without adding any value that I can see. Every concrete
> list is going to have to declare and implement every operation, so
> declaring them abstract an additional time seems like a waste of time.

There are good reasons for having an abstract base. Avoiding extra code is
not a good reason for getting rid of it.

However, your comments have prompted me to re-evaluate putting the concrete
in with the abstract. I think I must remove it (to childerhood). The idea
was to avoid a further instantiation (since a child package must be
generic), but imposing a concrete type on any would-be list (derived from
Abstract_List) is too mauch baggage. Shame: we're back to two
instantiations; it seems hard to get away from them!

> Is_Empty and Length are basic list operations that are missing.

Oops! In they go. (Got lost in the rush.)

> A component should not raise predefined exceptions such as
> Constraint_Error. Use meaningful exceptions such as Cursor_Is_Null.

For some conditions, yes. Will do.

> A concrete implementation should document the time complexity of every
> operation, so the client can make appropriate choices of operations.
> ...
> Each operation should document its pre- and post-conditions, where
> applicable. Each operation should document what exceptions it may raise
> and under what circumstances; since exceptions are generally indications
> that the client has violated a precondition, the documentation for
> preconditions is usually a good place to document exceptions.

Okay. I said the documentation was brief! I'll add this stuff ASAP.

> With some more work this could be an acceptable standard specification.

Cool!

--
Best wishes,
Nick Roberts

Re: List container straw man (NJR V4)

[Ted Dennison]

In article <9t69pc$jh6l$2@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>Okay, I've popped my own proposal on a web site:
>
>http://www.adaos.ukf.net

Just a quick note of explanation for my delay. I'm just today comming back up
for air after being down since last Thursday with a rather nasty virus of some
sort. Since Nick already has his up somewhere already, I'll see tonight about
providing a link to it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List container straw man (NJR V4)

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9t6srq$nbro$4@ID-25716.news.dfncis.de...
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3BF6CCD6.F7195928@acm.org...
> > ...
> > This is difficult to understand. This is the only place I've ever seen
> > the concept of "cursorage"; [...]

> The word 'cursorage' is my own Carrollean invention. Feel free to improve
> upon it.

Shouldn't it be "cursage"?

:-) :-) :-)
-- mark
"Foiled again!"

Re: List container straw man (NJR V4)

[Nick Roberts]

Lots of vitamin C, Ted! Get well soon.

--
Best wishes,
Nick Roberts




"Ted Dennison" <dennison@telepath.com> wrote in message
news:16bK7.30404$xS6.49016@www.newsranger.com...
> In article <9t69pc$jh6l$2@ID-25716.news.dfncis.de>, Nick Roberts says...
> >
> >Okay, I've popped my own proposal on a web site:
> >
> >http://www.adaos.ukf.net
>
> Just a quick note of explanation for my delay. I'm just today comming back
up
> for air after being down since last Thursday with a rather nasty virus of
some
> sort. Since Nick already has his up somewhere already, I'll see tonight
about
> providing a link to it.

If other people do this, we're going to end up with a doubly-linked list! Or
some other structure :-)