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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.129.103.5 with SMTP id b5mr1077786ywc.210.1504765014704;
        Wed, 06 Sep 2017 23:16:54 -0700 (PDT)
X-Received: by 10.36.33.4 with SMTP id e4mr146943ita.11.1504765014664; Wed, 06
 Sep 2017 23:16:54 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!border2.nntp.ams1.giganews.com!nntp.giganews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!q8no471860qtb.0!news-out.google.com!p6ni1366itp.0!nntp.google.com!o200no151679itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 6 Sep 2017 23:16:54 -0700 (PDT)
In-Reply-To: <693d41af-1da7-4c47-825a-198a082aaf9a@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=176.130.29.212;
 posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 176.130.29.212
References: <693d41af-1da7-4c47-825a-198a082aaf9a@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <806ff091-efd2-4625-afec-c7a6dc7886a8@googlegroups.com>
Subject: Re: Why does Ada.Iterator_Interfaces specify Next as a function
 rather than a procedure?
From: briot.emmanuel@gmail.com
Injection-Date: Thu, 07 Sep 2017 06:16:54 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Body-CRC: 2285939297
X-Received-Bytes: 2910
Xref: news.eternal-september.org comp.lang.ada:47963
Date: 2017-09-06T23:16:54-07:00
List-Id: <comp.lang.ada>

In my experience, a simpler approach is to use GNAT's Iterable aspect, whic=
h is way simpler and more logical (really just a thin layer about the usual=
 Cursor/Has_Element/Next/... operations).

Next is still a function in that context though, so maybe it doesn't really=
 solve your case. I am not sure why your next is a procedure. The idea is t=
hat a cursor is a relatively thin object, so light to copy around. If you h=
ave state, it should belong to an iterable.

For instance, I have used the following in GNATCOLL.Strings:

      type Index_Range is record
         Low, High : Natural;
      end record
         with Iterable =3D> (First       =3D> First,
                           Next        =3D> Next,
                           Has_Element =3D> Has_Element,
                           Element     =3D> Element);
      function First (Self : Index_Range) return Positive is (Self.Low);
      function Next (Self : Index_Range; Index : Positive) return Positive
         is (Index + 1);
      function Has_Element (Self : Index_Range; Index : Positive)
         return Boolean is (Index <=3D Self.High);
      function Element
         (Self : Index_Range; Index : Positive) return Positive
         is (Index);

      function Iterate (Self : XString) return Index_Range
         is ((Low =3D> 1, High =3D> Self.Length));

So from my container (XString), I get the iterable Index_Range (via Iterate=
) which could store some context information, and finally a Cursor. Since N=
ext receives the iterable, that might be good enough for your case.