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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,24d7acf9b853aac8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,CP1252 Path: g2news1.google.com!postnews.google.com!v15g2000yqe.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Sat, 7 Aug 2010 10:01:54 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5d0747cf-3226-4048-beb4-78b617fc19c9@v15g2000yqe.googlegroups.com> References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net> <8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com> <258zlxrv4fn6.1vszho1rtmf48$.dlg@40tude.net> <984db477-973c-4a66-9bf6-e5348c9b95f2@n19g2000prf.googlegroups.com> NNTP-Posting-Host: 95.152.65.220 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281200514 16464 127.0.0.1 (7 Aug 2010 17:01:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 7 Aug 2010 17:01:54 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v15g2000yqe.googlegroups.com; posting-host=95.152.65.220; posting-account=aMKgaAoAAAAoW4eaAiNFNP4PjiOifrN6 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.3) Gecko/20100524 Firefox/3.6.3,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:12935 Date: 2010-08-07T10:01:54-07:00 List-Id: On Aug 7, 5:38=A0pm, Jeffrey Carter wrote: > On 08/07/2010 12:23 AM, Natacha Kerensikova wrote: > Thus, there is a big difference in abstraction between C and Ada. C is ab= out > translating the problem into the capabilities of the solution language; A= da is > (or should be) about modeling the problem in the software. C is about cod= ing: > mapping everything onto a small set of predefined representations. Ada is= about > SW engineering: creating useful abstractions that represent important asp= ects of > the problem. Funnily, you're the first one shaking my resolve to learn Ada. Let's get everything straight: I'm amateur. I'm coding for fun. Well, I'll so be coding for a living too, but then I won't have a say in the language chosen. I like coding in C, and I don't care how efficient it is. There is not waste of time in a leisure activity. I'd rather have fun with C rather than doing the same thing 10x faster without fun. The only thing bothering me in C is that I often end up using dangerous construct. For example, *(struct foo **)((char *)whatever + bar.offset). While I'm perfectly fine with that, because I'm confident in what I'm doing, but I can understand it looks sloppy from the outside. My main motivation to learn Ada is publicize the concerns for robustness and correctness that might not be obvious from my C code. I was hoping to do Ada whatever I used to be doing in C: network programming, DS homebrew, etc. Am I misguided? Should I stop now? > Effectively using Ada requires a different way of thinking from using C o= r > assembler. You'll more quickly gain that mindset by asking how to approac= h > specific problems in Ada, rather than how to do something you did in C. Ok, so let's have a look at the grand picture. My main objective right now is to code a webserver in Ada. Yes, that's reinventing the wheel, but it does wonders for learning. Here is how I intended to do it, admittedly exactly like I would do it in C, could you please tell me how far I am from the Ada approach? I start by dividing the work into "modules" or "components", each containing a structure or a few related structures, along with whatever functions or procedures to deal with them. I thought this would map perfectly into Ada packages. Configuration files are S-expressions, in the form of (key value) pairs, gathered in sections like (section-name (key value) (key value)) =85 Webpage templates are also S-expressions, in the form "raw- html" (function arg1 arg2 =85) "raw-html" (function) "raw-html". The interesting thing being that arg1 arg2 etc are S-expressions and thus can be subtemplates too. As I'm more comfortable using components already coded and tested, I would code them from the lowest to the highest level: - first a component dealing with S-expression I/O, hence this topic. - then a component for configuration, which use the S-expression library and is used by other components either for program-wide configuration variables or for instance specific configuration - then a network component, gluing the rest of my program with whatever socket library I will use (AdaSockets or GNAT.stuff or C interfacing or whatever, don't know yet) - then a HTTP parsing component, taking data from the network component and configuration - then a general page component, dispatching requests to the relevant page objects - then a raw file component, a specific page responding to HTTP request with data taken directly from a file - then a template component, interpreting the function calls from S- expression templates - then a templated page component, another specialization of a page object, dealing with HTTP response and containing instance-specific data used by the template component. And that should be about it, I might encounter the need for other components, maybe for network I/O multiplexing or for logging or for caching templates etc. So, how bad is it? > An S-expression library might be a useful thing at a low-level, but few > applications should call it directly. Instead, there should probably be a= t least > one layer of abstraction on top of the low-level storage representation, = so that > the application only deals with appropriate application-level representat= ions of > the data. I have to admit in the above I don't really know what belongs to a library and what belongs to the application. But indeed, a S- expression package is a low-level thing, I'm well aware of that, I just can begin with high-level stuff if I don't have strong and tested low-level stuff to build upon. However the point of coding so many separate components is to be able to change the internals of one without having to touch everything else. Should I find someday a format so much better than S- expressions, I would only have one component to change. Should I want different formats for configuration and templates, that's a component to add, and maybe little modifications to configuration and/or template modules. And so on=85 > Here, your problem seems to be how to have a human-readable storage forma= t for > your applications. While there is merit to discussing the pros and cons o= f the > many existing formats to use, the Ada approach is to use an application-s= pecific > abstraction, hiding the implementation detail of which such format is eve= ntually > chosen. Is that so different than what I explained above? Thanks for your help, Natacha