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,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-06 10:17:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!demon!btnet-peer0!btnet-feed5!btnet!news.btopenworld.com!not-for-mail From: "Martin Dowie" Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? Date: Mon, 6 Oct 2003 17:16:20 +0000 (UTC) Organization: BT Openworld Message-ID: References: <3F803278.1020507@noplace.com> <3F816F2F.1010407@noplace.com> NNTP-Posting-Host: host81-128-239-244.in-addr.btopenworld.com X-Trace: sparta.btinternet.com 1065460580 17369 81.128.239.244 (6 Oct 2003 17:16:20 GMT) X-Complaints-To: news-complaints@lists.btinternet.com NNTP-Posting-Date: Mon, 6 Oct 2003 17:16:20 +0000 (UTC) X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MSMail-Priority: Normal X-Priority: 3 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: archiver1.google.com comp.lang.ada:324 Date: 2003-10-06T17:16:20+00:00 List-Id: "Marin David Condic" wrote in message news:3F816F2F.1010407@noplace.com... > I appreciate that there are plans to include stuff in the standard. Are > you going to provide a means by which it can be extended on a regular > basis? I can keep coming up with good ideas. I might even be willing to > help make them real. Is there a way to get them into most > implementations (or even my *own* implementation? By which I mean I can > extend the library with my own personal stuff) without waiting 10 years? I guess they will only form part of each RM every 10 years or so, but that doesn't mean the APIWG could provide some sort of "official status" to an API at any time in between. The problem with API developments is (apparently) getting them defined in RM-eze. > Are they children of the package Ada - and hence I'm not allowed to > modify or extend them in any way? (Or is that rule changing?) Is it > going to be a "reference implementation" that is released regularly or > is it "every vendor for himself?" Will it be in source code so I can > modify it if I don't like what it does? I think the rule has always been you can't add children to package Ada *in normal mode* but you can add grandchildren to existing packages, seemingly at will! At least in GNAT & ObjectAda it is easy. I make use of this by adding non-standard but portable (for me :-) extensions to say Ada.Calendar to add I/O. Again, for packages that don't require compiler 'magic', it would be nice for the APIWG to maintain a single reference implementation. I've got a Win32 ref-imp for AI-248 @ my web site and I'm doing a vanilla Ada one for AI-296. But note that the status of these 2 are very different. 248 is about one step away from being formally adopted to ISO approval but 296 is still a "work item" - neither may yet get in! > There's more to it than simply saying "we're adding some stuff to the > ARM..." I still think it is the entirely *wrong* answer to cast this > stuff into the concrete of the ARM - at least on its first pass through. > Let the ARM pick it up in the next revision if it proves stable. But get > a process set up to have an extensible library that can react quickly > outside the ARM. Again, I'd like the APIWG to do this and we should be all signing up for this asap and being *active*.