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=unavailable autolearn_force=no version=3.4.4 Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!news.stack.nl!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: container cursor type cannot be tagged Date: Thu, 28 Aug 2014 15:25:59 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <85ppfkxvwg.fsf@stephe-leake.org> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1409257561 13747 69.95.181.76 (28 Aug 2014 20:26:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 28 Aug 2014 20:26:01 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.dca.giganews.com comp.lang.ada:188714 Date: 2014-08-28T15:25:59-05:00 List-Id: "Stephen Leake" wrote in message news:85ppfkxvwg.fsf@stephe-leake.org... > In trying to build my own container package, I ran into a problem; the > Cursor type cannot be tagged. Which means we can't use "Cursor.op" > notation, which I've grown to really like. We of course noticed that when we originally designed the containers -- operations that only take cursors cannot be called in prefix notation. Originally, neither the container nor the cursor was tagged for this reason, but eventually we decided it was silly to make it impossible to use prefix notation at all just because it can't always be used. There doesn't seem to be a good solution that would allow the cursor to be tagged. But even untagged, you can't sensible extend the container because you really need to derive both the container and the cursor together. I tried to come up with a solution that would make both the container and cursor tagged, and would derive them in lock-step, but that gets to be a problem if the inherited routines are also primitive on other types. Full multiple dispatch would of course work, but we've talked about that enough here. (Thanks Dmitry! :-) ... > One solution to this is to define a new aspect Controlling_Type: > > overriding function First (Object : Iterator) return Cursor > with Controlling_Type => Iterator; > > which says to not use Cursor to dispatch calls to this subprogram. That > would be useful in other similar situations. I didn't find an AI on this > issue; would this be worth a proposal? Well, that's up to you. I'd think it's pretty weird; if one really wants a non-dispatching parameter, it should be declared as class-wide. Non-dispatching, non-class-wide tagged parameters almost always represent a bug in a program (we had a bunch in Claw, which tended to crash programs that derived things like fonts [tag check failures]; eventually we eliminated almost all of them). That's not so clear-cut for returns, but it seems weird to have a feature that only works for returns. > Another solution would be to provide another version of > Ada.Iterator_Interfaces, where Cursor is explicitly tagged, and these > functions use Cursor'Class. That seems more of a kludge. That seems to make more sense, honestly. But how are you dealing with the "can't have two tagged types" problem for the container itself? If it's untagged, you have the same problem about not allowing prefix notation, just in reverse (OK for cursors, bad for containers). If it's tagged, then the cursor can't be tagged. So I don't see much point in solving it at the iterator level if you can't solve it for the container itself (much more important). If it was me, I'd put a container parameter on every operation (which would be the prefix), and cursors would work soley like array indexes. (This is much better if you're writing preconditions and especially global declarations, since you can then refer directly to the container rather than having it implicit. The Ada.Containers design is sub-optimal for correctness, unfortunately.) In such a case, you wouldn't need a cursor to be tagged. You'd still want some sort of co-extension, however, (so a container extension would get a new cursor type) which Ada doesn't support. Randy.