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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3398541ec18f6aa6 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!wn11feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Taking another spanking. Reply-To: anon@anon.org (anon) References: <6f8fcf5b-09d7-40b6-9ac3-ed7e9f228b89@t21g2000yqi.googlegroups.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Sat, 06 Jun 2009 03:17:38 GMT NNTP-Posting-Host: 12.64.240.214 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1244258258 12.64.240.214 (Sat, 06 Jun 2009 03:17:38 GMT) NNTP-Posting-Date: Sat, 06 Jun 2009 03:17:38 GMT Organization: AT&T Worldnet Xref: g2news2.google.com comp.lang.ada:6321 Date: 2009-06-06T03:17:38+00:00 List-Id: As for GNAT.Sockets.Thin -- I expand what "Robert Dewar" the CEO and one of the chief authors of GNAT said in Aug 3, 1996 at 3:00 am. "If you can do it in C, you can do it in Ada! Use pragma Import and call exactly the same routines that you would call from C." In this case, I expand that to: Why not use GNAT package GNAT.Sockets.Thin instead of re-creating a few "pragma import" or re-creating the Thin package. Having GNAT.Sockets.Thin is more common and makes better code design then each file or package having its own set of "pragma import" statements. And then when IPv4 is completely phase out by all OS it is easier to write a GNAT.Sockets.Thin sub-class package that simulates the IPv4 routines which calls the IPv6 only GNAT.Sockets.Thin. Then all that is needed is to alter the with/use "GNAT.Sockets.Thin" statements to the new sub-class package name. That is, until one has the time or need to rewrite the program to use the IPv6 only routines in which the the program can again use "GNAT.Sockets.Thin". That is, until the next update to the IP, or more likey a replacement to IPv6 protocol. Plus, using "GNAT.Sockets" is great if your working with Streams or on the the client side. But if your creating non-stream server class appplication, its may be easier to go low-level (Thin). Especially if the program requires other low-level components such as ports or interrupts. Or includes a scanner or translation subsystem, before processing the data. As for Adacore updating it, the only problem that I see is that each year they have added more and more C code to GNAT system. In GNAT system you can look at the files "socket.c" and "gsocket.h". In GNAT 3.15p, they used only Ada code. So, they should follow the older design and their own CEO rule and use Ada with "pragma import" statements only and skip the C code completely. Now since, AdaCore has announced a conversion facility, why are they still using C code in the GNAT system? And why do they expand the amount of C in every additional yearly release (now at 71 c/h files). Starting with the conversion to GCC-4.x (a GCC major design change), and introduction of Ada 2005 they should of deleted all C coding in all current versions of GNAT. When they re-wrote "GIGI" backend routine to use GCC-4.x they should of use Ada and "pragma Imports" into the GCC compiler system only, but the "GIGI" routine is all most 7800 lines of C code. With Adacore using multiple files (like, the multiple system*.ads), and with them using the preprocessor (GNATPREP) to convert a multi-OS use single file into the packages that is needed for that OS and that version of GNAT, they could delete all C coding. So, what type of conversion facility is Adacore using, from looking at that the "C-like conditional expression" statement in the 2009 version of GNAT I would say that Adacore is trying to include or absob the C language into the Ada language, but if that's what they want they should create a new language like "Programming Language 2 or PL/2". Where "PL/2" would be created from Ada, C, and JAVA. For the "C2Ada", program and using Python, well Python or any other language should never had been used. Plus, I think most would prefer not to wait for Adacore to post a C-to-Ada program or a compiler that merges C like structure into Ada. And to show it is possible to use Ada only. Last year when it was made clear that GLADE was PHASE OUT, I created a Ada version Sun RPCGEN to takes the SUN RPC script file which has a C like structure and creates the Ada version RPC stubs. I used only GNAT 3.15p Ada, which only had one problem and that was Ada 95 does not contain "UNION"s. Later I create the SUN RPC subsystem which uses System.RPC. It works great in my Ada OS tests. Note: Why SUN RPC. Well, its non-Microsoft and non-JAVA based. Then there is lot of documentation and examples to work with. Plus, it is a RFC standard. In , sjw writes: >On Jun 4, 1:43=A0am, a...@anon.org (anon) wrote: > >Are you really just one person, or a collective? Sometimes you're >sensible, sometimes plain bananas .. this time on the sensible side. I >wish you'd admit to your real name! > >> But some like you talk that Ada should NEVER go beyond the RM and use >> Sockets, that is just wrong. Ada like all languages must be able to adapt= > and >> handle all devices both physical as well as virtual to be compatible to b= >e used >> for all applications. Else its the death by limitation of the language. > >Nothing wrong with GNAT.Sockets, use it all the time. But see no need >to go the .Thin level. If I did, I wouldn't moan at AdaCore for >changing it. > >> But then again, I think it was you that stated last year that if you rewr= >ote >> or updated "C2Ada" you would never write the program in Ada! > >c2ada is written in C, with some Python that I haven't had to >understand yet (and which seem to be related to converting C _bodies_ >to Ada, not a sensible project or one likely to lead to success IMO). > >So I might have said that I would rewrite it in Ada; but now, given >that AdaCore have announced a conversion facility, I think I'll find >something more worth while.