S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Robert A Duff on 11 Aug 2010 08:58 Natacha Kerensikova <lithiumcat(a)gmail.com> writes: > That's almost the point where > I stop trying to understand and just give up everything, Ada looks way > above my brain's capabilities. Most of this discussion is about the design of a program that might or might not use S-expressions. It's got little or nothing to do with Ada! If your brain can understand the complexities of C (when do arrays "decay" into pointers? how do you typedef an array of pointers to functions returning pointers to functions returning void? what's a "sequence point"?), then I assure you it can deal with Ada. - Bob
From: Dmitry A. Kazakov on 11 Aug 2010 10:10 On Wed, 11 Aug 2010 01:04:29 +0200, _FrnchFrgg_ wrote: > Le 10/08/2010 13:19, Dmitry A. Kazakov a �crit : >> On Tue, 10 Aug 2010 13:06:58 +0200, _FrnchFrgg_ wrote: > >>> Unification and pattern matching is independent of type inference. >> >> Did you mean the standard meaning of pattern matching instead of Standard >> ML's Volap�k? > > I meant pattern matching as a ML construct, which is in fact structural > unification. It can be done even without type inference, and only needs > some kind of polymorphism; essentially you have an object and an > expression made of (possibly nested) constructors, with leaves being > either constants or variables, and the unification engine answers > > a) if the object could be obtained by the sequence of constructors, or not > b) if yes, the content the variables would have had so that the sequence > of constructors would produce the object. > > For convenience, you often have a list of expressions, and the engine > executes the code of the first which fits the object. This translated into Ada terms, looks like an automated generation of literals/aggregates. There is one step required for Ada, i.e. interpretation of a text as code, since Ada is a compiled language. Main objection to all this is that it is hard-coded and involves the object's structure (not nominal). Ada has similar mechanism, also hard-coded and also structural. One generates S'Input and S'Output attributes for stream I/O of built-in container types (arrays and records). Another generates record and array aggregates. I don't like this either. I would like to see a more general mechanism that would allow user-defined recursive non-generic implementations. Because beyond literals and stream I/O there is an infinite number of cases where this pattern apply. And secondly it should work for user-defined opaque container types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Natacha Kerensikova on 11 Aug 2010 11:30 On Aug 11, 2:58 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > If your brain can understand the complexities of C (when do > arrays "decay" into pointers? Always, except when they're an argument of sizeof, unary &, or a string literal used to initialize an array (C99 §6.3.2.1.3). Though I have to admit from the top of my head I only remember sizeof and that there are three of them, after think a bit I remembered unary &, and I had to look up the Standard to find out the thrid one (even though I use fluently this feature when I needed it). > how do you typedef an array > of pointers to functions returning pointers to functions > returning void? typedef void (*voidfn)(arguments unspecified above); typedef voidfn (*returning_voidfn)(other arguments unspecified above); typedef returning_voidfn wanted_type[SIZE_UNSPECIFIED]; Now of course this is probably less impressive than the much-less- readable version doing everything in one statement: typedef void (*(*wanted_type[SIZE])(void))(void); > what's a "sequence point"? Basically, points in the program flow between which whatever should happen happens in an undefined order. They happen roughly at commas (expression separator), semicolons (statement separators) and lazy logical operators. > ), then I assure you it can deal with Ada. But what's the point of knowing all this when one can't design a three- digit LOC program properly? It's just like knowing the dictionary contents by heart without knowing anything about grammar. Thanks for your time, Natacha
From: Simon Wright on 11 Aug 2010 13:32 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Tue, 10 Aug 2010 22:22:02 +0100, Simon Wright wrote: > >> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >> >>> Yes, if TCP sockets is what you use. There is a hell of other >>> protocols even on the Ethernet, some of which are not stream-oriented. >> >> We leverage stream i/o via UDP (which on GNAT is seriously broken, >> because it tries to do an OS sendto() for each elementary component! > > Wow! Even in the latest GNAT Pro/GPL? > > I am asking because AdaCore fixed this very issue for String'Write, which > did Character'Write per element. Was it String-only fix? There was an efficiency problem, where GNAT did as you say. I raised a ticket but don't recall what happened about it (we are stuck with an archaic GNAT, don't ask). But I think you will still find that a String is still written as a C_Sendto of an Integer (Item'First), another Integer (Item'Last) and then (if this change has been made!) the String itself. Checked in 6.2.2. The best cure IMHO is to refuse to return a Stream for a Datagram_Socket.
From: Dmitry A. Kazakov on 11 Aug 2010 13:53
On Wed, 11 Aug 2010 18:32:39 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > >> On Tue, 10 Aug 2010 22:22:02 +0100, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >>> >>>> Yes, if TCP sockets is what you use. There is a hell of other >>>> protocols even on the Ethernet, some of which are not stream-oriented. >>> >>> We leverage stream i/o via UDP (which on GNAT is seriously broken, >>> because it tries to do an OS sendto() for each elementary component! >> >> Wow! Even in the latest GNAT Pro/GPL? >> >> I am asking because AdaCore fixed this very issue for String'Write, which >> did Character'Write per element. Was it String-only fix? > > There was an efficiency problem, where GNAT did as you say. I raised a > ticket but don't recall what happened about it (we are stuck with an > archaic GNAT, don't ask). > > But I think you will still find that a String is still written as a > C_Sendto of an Integer (Item'First), another Integer (Item'Last) and > then (if this change has been made!) the String itself. > > Checked in 6.2.2. > > The best cure IMHO is to refuse to return a Stream for a Datagram_Socket. We never used the stream interface with TCP sockets either. Socket stream is certainly a nice-to-have feature, but, I don't know, we didn't even considered to use it. Somehow it was out of question from the start. Otherwise, we would have noticed it, since we are doing a lot of heavy-duty TCP and UDP stuff over GNAT.Sockets. In the beginning we a bit suspicious and considered a possibility to use another socket library, but GNAT.Sockets worked so well that we dropped the idea. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |