S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Natacha Kerensikova on 13 Aug 2010 05:32 On Aug 12, 8:51 pm, Jeffrey Carter <spam.jrcarter....(a)spam.not.acm.org> wrote: > On 08/12/2010 02:26 AM, Natacha Kerensikova wrote: > > There are situations when a memory representation of S-expressions is > > not needed, and the tcp-connect example here seems to be such a case. > > That's why I imagined TCP_Info as a client of Sexp_Stream instead of a > > client of the second package. > > Not needed, perhaps, but it makes things clearer and more reusable if it is used > anyway. Well indeed, I do consider readability and simplicity (they often come together) as one of the most important criteria when choosing an interface. I think I didn't explained the whole thought process above, my bad. When I wrote this I couldn't think of any way to write clearer or simpler code with any of the two proposed packages (stream or memory based), because of the basic argument that 8 nodes have to be somehow created anyway and couldn't think of any way of doing that except by creating them one by one (be it with a sequence of procedure calls or a bunch of nested function calls). So when complexity and readability are equal, I go for the least amount of dependencies. Of course finding a way to make S-expression building much clearer with a given interface would be a huge argument in favor of the interface, no matter its level. > > To achieve such an interface, the client has to build an in-memory S- > > expression object. In the tcp-connect example, there are eight nodes > > (five atoms and three lists). They have to be somehow built, and it > > doesn't look like a simple initialization. > > Perhaps not. But for each kind of thing you want to store using this > representation, it need be done only once, and then reused: > > S : S_Expression := To_S_Expression (TCP_Info); Unless I missed something important, it looks like it only moves the problem around. While a To_S_Expression function does make a TCP_Info'Write simple and one-operation and all, complexity is only transferred to To_S_Expression which will still have to do the dirty job of creating 8 nodes. > > The second interface I proposed, with a lot of nested calls, builds > > the S-expression object with functions looking like: > > function NewList(Contents, Next: S_node_access) return S_node_access; > > function AtomFromWhatever(Contents: whatever, Next: S_node_access) > > return S_node_access; > > An aside on Ada style: Ada is not case sensitive, and many of us reformat code > to make it easier for us to read. The resulting identifiers such as Newlist and > Atomfromwidget are not very readable. This is why the convention is to use > underlines between words. Yes, I have not managed yet to get that habit. I try to use a Underscore_And_Capitalization style (not sure whether it's the usual Ada idiom or not), but sometimes in the heat of action I forgot to do it (funny thing that identifier that slip end up to be camel cased, while my C habit is underscore and lower case). > >> Your TCP_Info-handling pkg would convert the record into an S-expression, and > >> call a single operation from your S-expression pkg to output the S-expression. > > > That's the tricky part. At least so tricky that I can't imagine how to > > do it properly. > > I'm not sure what you think is tricky about it. Clearly you see how to output an > S-expression: You're not the only one having trouble understanding that part. I'm not good at expressing myself :-( What I found tricky is the "single operation" part. Building 8 nodes in a single operation does look very difficult, and while Ludovic's trick of building them from an encoded string is nice, it makes we wonder (again) about the point of building a S-expression object before writing it while it's simpler and clearer to write strings containing hand-encoded S-expressions. Thanks for your remarks, Natacha
From: Natacha Kerensikova on 13 Aug 2010 05:43 On Aug 12, 11:22 am, Georg Bauhaus <rm- host.bauh...(a)maps.futureapps.de> wrote: > On 8/12/10 10:53 AM, Natacha Porté wrote: > > > I have to admit I was quite surprised to find my old way of using S- > > expressions to be so extremely more difficult in Ada compared to C > > (whaddoyoumean I can't just feed to strcmp() raw data I've just read > > from a file!?). > > You can "=" just those bytes: you'll just have to drop type > checking by using an instance of Unchecked_Conversion of > the-bytes-you-read to String. Isn't that more-than-a-bit un-Ada-ish? But then again there might be simple command_string = String(array_of_read_octets); if command_string = "my-command" them which would solve the problem. And if said string converter/constructor doesn't exist, I guess the same thing can be done with an ad-hoc String_From_Atom function. But it would be nice if there was a way to make that operation a no-op in machine code (at least on platforms where array-of-octets and String share the same representation, which should be quite often considering the definition of Character). > > But on other hand it might be a good thing to be > > shaken into realizing the deep implication from the difference in > > typing strength. > > The 12K SLOC Python programs on my screen surely would > be a little easier to rewrite if Python had explicit typing. > assert isinstance(this, that) seems a helpful workaround, > but tedious in comparison to strong typing during translation... Explicit typing is what made me drop python. I remember very well the last straw, when I spend a long time chasing around a bug which was cased by a 1 given as a function argument, which was then passed to another function and then another where it divided by 2. However the context was completely floating point, so the 0 obtained was quite a surprise compared to the expected 0.5. And even today I still think 1 and 2 are completely valid floating-point constants. Natacha
From: Dmitry A. Kazakov on 13 Aug 2010 05:51 On Fri, 13 Aug 2010 02:10:23 -0700 (PDT), Natacha Kerensikova wrote: > On Aug 13, 12:25�am, "Jeffrey R. Carter" >> provided a more detailed grammar (using the >> trailing '*' from regexps rather than {}) with some additional options. > > Is one of them more standard than the other? {} is from EBNF http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form used in the meaning "repeat or nothing". However earlier, at least I remember it so, {} was rather used as mere grouping brackets of required alternatives, and the number of repetitions where written as a superscript number on the closing bracket. So the newish {P} were denoted as [P]*. And [P] itself was an abbreviation of {P|} etc. > I can assure you what I'm doing is completely conform with Rivest's > standard proposition. I don't know how come it has not reached the > status of full-fledged RFC (while real RFCs like SPKI do depend on > it), Probably because there already was a standard, the Abstract Syntax Notation: http://en.wikipedia.org/wiki/ASN.1 -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 13 Aug 2010 06:30 On 13.08.10 10:56, Natacha Kerensikova wrote: > Ada arrays are statically sized, Not quite, but I think you mean that once an array is allocated, you can't add more components than are declared by the index constraint? Example: procedure Uses_Array (N : Positive; ...) is X : array (1 .. N) of Character; -- now fixed to N compoments begin... But Ada's Container packages can provide for the desired flexibility. There are containers of homogeneous components and containers of heterogeneous components. The latter have _Indefinite in their package's names. Example: package Vecs is new Ada.Containers.Indefinite_Vectors (Element_Type => Types.Heterogenous'Class, Index_Type => Positive, "=" => Types.Eq); (Vecs.Vector objects will grow as needed.) Another option is to instantiate a "definite" container generic with a pointer type, which is definite. Its access values will point to any object in some hierarchy. (This can mean pointers to any objects that share the same interface (Ada 2005 keyword), so types need not even be rooted at the same one parent type, I think). For example package S_Lists is new Ada.Containers.Doubly_Linked_Lists (Element_Type => Some_Hier_Ptr, "=" => ...); Georg
From: Ludovic Brenta on 13 Aug 2010 11:52
Natacha Kerensikova <lithiumcat(a)gmail.com> writes on comp.lang.ada: > What I found tricky is the "single operation" part. Building 8 nodes > in a single operation does look very difficult, and while Ludovic's > trick of building them from an encoded string is nice, it makes we > wonder (again) about the point of building a S-expression object > before writing it while it's simpler and clearer to write strings > containing hand-encoded S-expressions. The only use case for constructing an S-Expression tree in memory and then writing it out is when the S-Expression is very dynamic. For example, when you want to save the state of your application, e.g. the cache of a web browser, in a structured way. Or when you want to save a tree, the contents and structure of which are unknown in advance. If the S-Expression is static or mostly so, then by all means write it by hand. -- Ludovic Brenta. |