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,2d2df3e9ad18fa63 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-20 11:33:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding References: <3EF338C5.2010005@cogeco.ca> X-Newsreader: Tom's custom newsreader Message-ID: NNTP-Posting-Host: 12.234.13.56 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1056134034 12.234.13.56 (Fri, 20 Jun 2003 18:33:54 GMT) NNTP-Posting-Date: Fri, 20 Jun 2003 18:33:54 GMT Organization: AT&T Broadband Date: Fri, 20 Jun 2003 18:33:54 GMT Xref: archiver1.google.com comp.lang.ada:39498 Date: 2003-06-20T18:33:54+00:00 List-Id: >But there _are_ problems WRT Ada. The first that comes to mind is >the whole error handling approach. POSIX likes the idea of an errno >value with errno codes. The Ada approach often uses exceptions, and I have the paper version of IEEE 1003.5-1992 which specifically has a discussion of why that Ada binding to POSIX uses exception handling instead of errno. ISO/IEC 14519 appears to be a successor, covering more ground (eg sockets). The Ada binding is thick in the sense of using exceptions, strong typing, generics, tasking, etc, but it's still pretty "close to the hardware". It also was designed pre-Ada95. In designing CLAW, we studied the 1003.5-1992 book, but in many cases went for a higher abstraction level. For instance, claw sockets need merely Open, Write, Close (Close is optional, actually, thanks to Finalization) with lots of stuff, like the multiple states a socket can be in, happening "under the hood". There are projects that need the detailed level of control, and there are projects that will be implemented faster with the simplified interface. I don't think a one-size-fits-all standard socket binding would be adequate.