S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Georg Bauhaus on 9 Aug 2010 18:32 _FrnchFrgg_ wrote: > I don't know enough ada to even imagine how you would implement such a > thing in Ada, if possible, or whether it already exists (but I gather no > from what you say). For the basic types like discrete types, value matching is fully supported and re1quired. type Color is (Red, Green, Blue); C : Color; case C is when Red => Add_Green; when Green => Add_Blue; end case; 7. case C is | >>> missing case value: "BLUE" Some of the structure matching can, I think, be handled by choosing meaningful type hierarchies (Tree, Leaf and the like) and use O-O overridings (for Tree and Leaf, respectively). Georg
From: Ludovic Brenta on 9 Aug 2010 20:11 Natacha Kerensikova <lithiumcat(a)gmail.com> writes: > On Aug 9, 8:49 pm, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote: >> I pursued that idea a little further and actually wrote an embryonic >> S-Expression library. I'm not entirely satisfied with it because it >> uses copy semantics instead of reference semantics and so is probably >> inefficient. But it does demonstrate how to read and write >> S-Expressions on a stream (e.g. a file). Also, it shows how to >> hex-encode and hex-decode blobs, which I've modelled as Storage_Arrays. >> >> You can browse the sources here: >> >> http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.s_... >> >> Enjoy. (the license is the GPLv3 or later). > > Interesting, though it seems your code won't like strings containing a > double-quote. Right; that's a minor detail and easy to correct by e.g. preceding embedded double-quotes with a backslash. > However, the principal conclusion I draw from reading this is that I'm > still far from having the Ada level required to write anything like > that (since I can't even understand everything while reading it). I think I could simplify the library with some additional thought. What you see is but a first iteration :) > Still, from what I understood, I'm not fond of the idea of having to > write type-to-atom conversion procedure while they already exist. > > It occurred to me that most types already know how to serialize > themselves, through the Stream subsystem. Strings, Unbounded_strings, > Integers, Float, etc, can all be read from and written into a stream. > So the code to convert them into file-suitable Stream_Element_Array > exist. Won't be a pity not to reuse it? > > Pursuing this idea leads to a library quite different from what I had > in mind when I started this thread. Let's call it Sexp_Stream, which > would be derived from Root_Stream_Type. Then Read and Write procedure > are called (from what I understand) by type'Read and type'Write after > said type has turned itself into a Stream_Element_Array. That would > cover atom I/O, and some procedures must be added to cover the list I/ > O part. > > I think I can imagine how the writing part would happen: > after having initialized a Sexp_Stream object with various > information, including an underlying stream where the S-expression > would be actually written, the application would use the Write > procedure to append an object as an atom to the current node, and the > newly appended atom would become the current node. List procedure > would be called something like List_Open, to open a new list and > append following nodes into it, and List_Close, to close the current > list and come back to the previous list. > > Using my tcp-connect example, it would look like this (please excuse > Ada syntax error and focus on the idea): > > Sexp_Stream.Open(SxStream, underlying_stream, ...); > Sexp_Stream.Open_List(SxStream); > String'Write(SxStream, "tcp-connect"); > Sexp_Stream.Open_List(SxStream); > String'Write(SxStream, "host"); > String'Write(SxStream, Hostname); > Sexp_Stream.Close_List(SxStream); > Sexp_Strean.Open_List(SxStream); > String'Write(SxStream, "port"); > Integer'Write(SxStream, PortNumber); > Sexp_Stream.Close_List(SxStream); > Sexp_Stream.Close_List(SxStream); > > Now I have to admit I don't know how to specify the reading part of > such a Sexp_Stream. I guess I would need the notion of a current node, > with a function telling the application whether the current node is a > list or an atom, type'Read converting the current atom into said type > (and raising an exception when the current atom is a list), and some > procedures to get to the next node, to the frist node following the > current list (i.e. up one level), and when the current node is a list > to go the first node of the list (i.e. one level deeper). > > However such a library wouldn't cover all my S-expression needs, > because I sometimes need to keep S-expressions into memory, so there > would be another package for in-memory S-expressions, which would have > to interact nicely with Sexp_Stream. That's exactly what my library is for: it lets you build S-Expressions in memory and serialize them to a stream (adding any parentheses or quoting necessary along the way) and, conversely, read from a stream and build in-memory S-Expressions. At this level, the value of any atom is an unbounded_string; the semantics are left to the application. The To_Atom and From_Atom functions are there to help you build a high-level layer on top of the S-Expression layer. The "test.adb" program contains such a higher layer: it defines a (simple) record type containing an integer and a boolean (enumerated type) and encodes it into an S-Expression containing strings, and back. I'll add a generic to encode arbitrary hashed_maps into S-Expressions of the form ((key value) (key value) ...) later on, if you're interested. > So, how does it sound? Is it totally crazy? Is it totally not-Ada? Is > there something right in there? I don't think "Ada" or "not Ada" should be the question; the proper question should be "is it reusable and maintainable?" > For Jeffry Carter (and anybody interested in helping me understand the > Ada way): here is how it looks like when I haven't thought much about > it. Notice that all this is completely from the point of view of the > application using the package, with very few implementation choices. > If I knew Ada, wouldn't these explanations be pretty much the contents > of the specification file, with about everything from the body being > still to invent? How Ada-ish is that thought process? > > > Thanks in advance for your reviews of my ideas, > Natacha -- Ludovic Brenta.
From: Randy Brukardt on 9 Aug 2010 20:51 "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message news:wccbp9bspzy.fsf(a)shell01.TheWorld.com... > Simon Wright <simon(a)pushface.org> writes: > >> Natacha Kerensikova <lithiumcat(a)gmail.com> writes: >> >>> and I don't know either how to deal with cases where Stream_Element is >>> not an octet. >> >> By ignoring them, I think! > > Are there any such cases in the real world? There are machines > in the embedded world where Storage_Element is not 8 bits. Not sure if it still exists in the real world, but the compiler we did for the Unisys mainframes used Stream_Element'Size = 9. (The Unisys mainframes are 36-bit machines.) Stream_Element'Size = 8 would have made the code for handling arrays awful. Similarly, Character'Size = 9 on that machine. While the upper bit was not used in the representation, this is surely not an Octet. > But any machine that's hooked up to any sort of network > is going to be talking Octets, I think. Does anybody know of > counterexamples? The network interfaces on the Unisys machines required binary or text mode settings: in text mode, the extra bit was just dropped; in binary mode all of the bits were sent (not sure precisely how that was done, it was in the OS). > Perhaps Stream_Element should have been defined as exactly > 8 bits. Perhaps it should have been called "Octet". That would have made a compiler for the Unisys machines impossible; it would have made streaming impossible. There is no sane way to put 36-bit values into Octets - the only way that would have worked would have been to use 16-bits for every 9-bit byte. Whether this is a significant consideration today (in 2010) is debatable, but it surely was a real consideration back in 1993-4. So Ada 95 could not have made this choice. Randy.
From: Jeffrey Carter on 9 Aug 2010 20:57 > Natacha Kerensikova<lithiumcat(a)gmail.com> writes: > > For Jeffry Carter (and anybody interested in helping me understand the > Ada way): here is how it looks like when I haven't thought much about > it. Notice that all this is completely from the point of view of the > application using the package, with very few implementation choices. > If I knew Ada, wouldn't these explanations be pretty much the contents > of the specification file, with about everything from the body being > still to invent? How Ada-ish is that thought process? In general, describing it from the point of view of "the application using the package" (often referred to as "the client") is the purpose of the specification. The body is for the implementation, usually best left until the specification is finished. On the other hand, your proposed operations seem unnecessarily low level for the client. You have an internal representation, which is probably hidden from the client, and an external representation, and operations to write an object of the internal representation to that external representation and read the external representation to create an object of the internal representation. Thus, your client should probably invoke a single operation to write an object, and another single operation to read. -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Jeffrey Carter on 9 Aug 2010 21:00
On 08/09/2010 05:51 PM, Randy Brukardt wrote: > > Not sure if it still exists in the real world, but the compiler we did for > the Unisys mainframes used Stream_Element'Size = 9. (The Unisys mainframes > are 36-bit machines.) Stream_Element'Size = 8 would have made the code for > handling arrays awful. What was Storage_Unit? 36? -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |