Re: List container strawman 1.2

[Ted Dennison<dennison@telepath.com>]

In article <87d72qfrtd.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Oops, sorry.  "Such errors" referred to errors in using the list
>container routines, IOW these usage errors can lead to erroneous
>execution.

I used the term "bouded error", because it seems to me that the limits for what
nasty things can happen is definable. Its probably not worth wasting this much
breath over though. :-)


>What about pragma Assert? It's similar.

It's also Gnat-specific. Anyway, I think it would be easier for acceptance of
this facility if there were one implemtation (spec and body) that could (not
must but could) be used by any compliant compiler vendor.

>Hmm, I haven't completely followed the discussion, but there was a
>proposal for including a list pointer in the Location/Position type,
>and it made sense to me.  If this proposal is followed, all data would
>be there to verify these operations (the only thing missing is
>verification of the list access value itself).

Even if we did that, the declarations of List and Location in the private part
of the spec would have to be different depending on what approach is used.
That's why we don't want to move to a reference implementation for the body
until we get this issue resolved. 

>BTW, there's an unnecessary negative in the Sort routine:
>
>    generic
>       with function Reverse_Order (Left, Right : in Element) return Boolean;
>    procedure Sort (Subject : in out List);
>
>I think it would be better to test for "In_Order" ("<=") because this
>seems to be more natural.  In addition, we should probably specify if
>Sort is stable or not.

You have a point. My thinking was that since the routine is a boolean, and can
be substitued with any matching function whatsoever, its generic name should say
what action needs to be done when the condition is true, rather than stipulating
the conditions under which *nothing* will be done.

Perhaps some comparative code would help folks decide:

Assume:
  package Integer_List is new Containers.Lists.Unbounded (Integer);

Version 1:
  procedure Sort_Increasing is new Integer_List.Sort (Reverse_Order => ">");

Version 2:
  procedure Sort_Increasing is new Integer_List.Sort (In_Order => "<");

I'm not sure what you mean by "Stable". If you mean some flag will be set and
every insertion after that will also call "Reverse_Order" to keep things sorted
that way, I'd say no. Hmmm. I'd meant to add an "Insert_Sorted" routine for that
issue. Perhaps you were leading up to that.

---
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.