From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e382b50ddc696050
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-06 11:18:01 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: List Strawman JC01
Date: 06 Dec 2001 14:09:50 -0500
Organization: NASA Goddard Space Flight Center
Message-ID: <un10ww4g1.fsf@gsfc.nasa.gov>
References: <3C0DB9D0.7184868A@acm.org>
 <smuP7.50028$xS6.82871@www.newsranger.com> <3C0EB851.77E7172A@boeing.com>
 <xMMP7.51415$xS6.84581@www.newsranger.com>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1007665976 26222 128.183.220.71 (6 Dec 2001
 19:12:56 GMT)
X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov
NNTP-Posting-Date: 6 Dec 2001 19:12:56 GMT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Xref: archiver1.google.com comp.lang.ada:17524
Date: 2001-12-06T19:12:56+00:00
List-Id: <comp.lang.ada>

Ted Dennison<dennison@telepath.com> writes:

> In article <3C0EB851.77E7172A@boeing.com>, Jeffrey Carter says...
<snip>
> >This is much less clear than "<". Everyone knows what "<" does.
> >"Swap_Items (L, R ...) return Boolean;" is meaningless.
> 
> In the context of a boolean expression, yes everyone knows. In the context of
> the internals of a sort routine, its completely undefined. Is the "Left"
> parameter the "Front" side or the "Back" side? Does a "True" result mean its out
> of order or in order? You can supply answers to these questions I'm sure, but
> the answers will be fairly arbitrary. They are certianly not self-evident.

I agree with Ted; we need to be careful about making implicit
assumptions about direction. 

But this actually points to an inconsistency in Ted's current
strawman. It says:

-----------------------------------------------------------------------------
-- Sorting sub-package.
-- To sort in increasing order, use the ">" routine for the Reverse_Order
-- parameter. To sort in decreasing order, substitute your "<" routine for
-- the Reverse_Order parameter. :-)
-----------------------------------------------------------------------------
generic
   with function Reverse_Order (Left, Right : in Element) return Boolean;
package Sorting is


So it is currently using "Left" and "Right", rather than "Front" and
"Back".

Well, actually the Sort procedure doesn't say anything about
direction. It needs to say "Direction is implicitly Front to Back", or
it needs to take a Direction parameter.

Perhaps the documentation for Reverse_Order could say:

-- Function Reverse_Order is called with Left being the current
-- iteration position, and Right being the next one. Return True if
-- they should be swapped.

But that assumes Sort is done via some iteration scheme. Hmm. This is
not easy!

-- 
-- Stephe