Re: List container strawman 1.2

[Florian Weimer <fw@deneb.enyo.de>]

Ted Dennison<dennison@telepath.com> writes:

> In article <87668ivpw8.fsf@deneb.enyo.de>, Florian Weimer says...
>>You should not call it a "bounded error" because that would be
>>confusing.  Such errors result in erroneous execution with typical
>>implementations.  For debugging, we might add an additional variable
>
> I thought the whole point of "bounded errors" was that they *don't*
> result in erroneous executions.

Oops, sorry.  "Such errors" referred to errors in using the list
container routines, IOW these usage errors can lead to erroneous
execution.

> That's a technique I have to say I've never used in final production
> code, and is certianly not used anywhere in the rest of the current
> Ada library.

What about pragma Assert? It's similar.

> Exactly what benifit would we get from this?

You would get a debugging version without the need to duplicate a lot
of code.

> I don't think you can use it to switch between safe active iterators
> and unsafe "Locations", as the declarations would have to be
> different too.

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

But perhaps it isn't worth the trouble, I don't know.

>>What about terminating Iterator prematurely using an exception?  It's
>>a bit ugly, granted, but with the "out" parameter approach, I've
>>managed to forget to set the parameter more than once.  If the Quit
>>parameter is going to stay, we shouldn't use a Boolean type for it,
>>but a new enumeration type.
>
> I suspect we would have some violent objections to that idea from
> some people

Yes, of course, and I understand these objections.

> What would you say to the proposal we had to make it "in out" with a
> default?

That's probably better.  I think we can assume that most of the time,
the user wants to iterate over the entire structure, so we could
specify a default value of "Continue", and in many cases, the user
wouldn't have to deal with this parameter at all.

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.

(And I wouldn't include the stream attributes in the main package, but
in a child.)