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=-2.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fa18fb47ddd229a7
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-12-10 05:38:08 PST
Path: 
 archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!fr.ip.ndsoftware.net!nerim.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail
From: "amado.alves" <amado.alves@netcabo.pt>
Newsgroups: comp.lang.ada
Subject: RE: Proposed change to BC iterator parameters
Date: Wed, 10 Dec 2003 13:36:47 -0000
Organization: Cuivre, Argent, Or
Message-ID: <mailman.69.1071063420.31149.comp.lang.ada@ada-france.org>
NNTP-Posting-Host: lovelace.ada-france.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Trace: melchior.cuivre.fr.eu.org 1071063420 45199 80.67.180.195 (10 Dec 2003
 13:37:00 GMT)
X-Complaints-To: usenet@melchior.cuivre.fr.eu.org
NNTP-Posting-Date: Wed, 10 Dec 2003 13:37:00 +0000 (UTC)
To: "Simon Wright" <simon@pushface.org>,
	<comp.lang.ada@ada-france.org>
Return-Path: <amado.alves@netcabo.pt>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Proposed change to BC iterator parameters
Thread-Index: AcO+4ky0nqzD6lMdQryHUXtG2qEgeAAPfqQ4
X-OriginalArrivalTime: 10 Dec 2003 13:36:49.0338 (UTC)
	FILETIME=[A9B301A0:01C3BF22]
X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org
X-BeenThere: comp.lang.ada@ada-france.org
X-Mailman-Version: 2.1.3
Precedence: list
List-Id: Gateway to the comp.lang.ada Usenet newsgroup
	<comp.lang.ada.ada-france.org>
List-Unsubscribe: <http://www.ada-france.org/mailman/listinfo/comp.lang.ada>,
	<mailto:comp.lang.ada-request@ada-france.org?subject=unsubscribe>
List-Post: <mailto:comp.lang.ada@ada-france.org>
List-Help: <mailto:comp.lang.ada-request@ada-france.org?subject=help>
List-Subscribe: <http://www.ada-france.org/mailman/listinfo/comp.lang.ada>,
	<mailto:comp.lang.ada-request@ada-france.org?subject=subscribe>
Xref: archiver1.google.com comp.lang.ada:3308
Date: 2003-12-10T13:36:47+00:00

<<...
   generic
      type Param_Type is private;
      with procedure Apply (Elem : in Item;
                            Param : in Param_Type;
                            OK : out Boolean);
   procedure Visit_With_In_Param (Using : in out Iterator'Class;
                                  Param : in Param_Type);
>>

I've never found a situation where the following much simpler signature =
wouldn't suffice:

   generic
      with procedure Apply (Elem : in Item);
   procedure Visit_With_In_Param (Using : in out Iterator'Class);

with premature termination of the iteration done by raising inside Apply =
an exception which Visit_With_In_Param propagates by definition.

<<...      type Param_Type (<>) is limited private;

As I understand it, this allows users much more freedom (you can even
use a tagged type provided you instantiate with Tagged_Type'Class)...>>

Strictly you don't need the limited formal for (unlimited) tagged or =
class actuals. You need the limited formal for limited actuals, whatever =
their class. Limitedness is completely orthogonal to definiteness. I do =
like indefinite formals, but I pass well without limited ones. Most =
limited formals I've seen in libraries are accompanied by a formal =
assignment operation or some such, which prety much defeats the purpose =
of their (formal) limitedness, i.e. their logic is in clash with their =
definition.