S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Natacha Kerensikova on 9 Aug 2010 14:20 On Aug 8, 11:08 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> writes: > By the way, one defense of modular types I've heard is that > they are used in mathematics. True. But mathematicians do > not use _implicit_ mod. They say things like "X = Y (mod N)", > which is pronounced "X is congruent to Y (modulo N)". > Congruent, not equal. Actually past a certain level, they don't explicit mod anymore. I don't remember hearing many "modulo" in Galois field classes. And neither when dealing with stuff like an n-bit integer representing a member of Z/2Z [X] quotiented by a n+1 degree polynomial (Reed-Solomon stuff). And then you're overloading "+" with something very xor-like Hoping I'm not disrupting anything, Natacha
From: Georg Bauhaus on 9 Aug 2010 14:29 On 09.08.10 19:05, Robert A Duff wrote: >>> 7. No array index of > I think Dmitry was complaining in 7 that you can't do this: > > type Bit_Map is array(...) of Boolean; > type T is array (Bit_Map) of Something; -- Illegal index type. > > whereas if Bit_Map is modular then you CAN do that. Always takes a while until my slow head grasps Dmitry's non-Ada semantics. case {T0 x T1 x T3} is when ... => ... Static dispatch tables on composite types' values switching to non-subprogram sequences of instructions wrapped in a case statement that's likely to have impressive combinatorial properties... Is there no better way than this? Experimenting further, what will be a useful type of case_statement_alternative's discrete choice list, then? One that can be explored programmatically? Georg
From: Natacha Kerensikova on 9 Aug 2010 14:32 On Aug 9, 5:14 pm, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > On 09.08.10 16:38, Dmitry A. Kazakov wrote: > > > Just one example from a huge list, why "in" is not an operation? > > > if 0 /= (Mode and Alarm) then -- Isn't it awful? > > > why am I not allowed to have: > > > if Alarm in Mode then > > Is anything wrong with packed arrays of Booleans for status thingies? In C for such things I usually use a struct bitfield. I guess the Ada equivalent would be a record of Booleans, with a pragma or something to have them packed together. Would there be anything wrong with that? It seems to me more readable than the above IFs, though from what I understood from the rest of the thread it would make CASE on multiple bit difficult, and it won't allow slicing (which I'm not sure is a bad thing, readability-wise). Is there anything else? Natacha
From: Natacha Kerensikova on 9 Aug 2010 14:37 On Aug 9, 5:40 pm, Simon Wright <si...(a)pushface.org> wrote: > Natacha Kerensikova <lithium...(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! That's something I'm quite uncomfortable with. However I see the point of the other related posts here. So my question is, if I assume Stream_Element is an octet, is there a way to make compilation fail with an explicit error message when the assumption doesn't hold? C's preprocessor allows this through a #if on CHAR_BITS and a #error to stop compilation with a custom message. Any Ada equivalent? Thanks for your help, Natacha
From: Ludovic Brenta on 9 Aug 2010 14:49
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes on comp.lang.ada: > Natacha Kerensikova <lithiumcat(a)gmail.com> writes: >> Hi, >> >> I'm trying to learn Ada, coming from a C background. The first thing I >> planned to code is a S-expression parser, because it's quite easy (at >> least in C, less than 1000 lines including comments and memory >> handling (dynamic arrays reinvented)) and very useful considering >> almost all my existing programs use S-expressions as a serialization >> format. >> >> To describe briefly S-expressions, I consider them to be the simplest >> existing data organization beyond raw sequences of bits. They are >> basically lists of elements, each element being either a list or an >> atom, and atoms being raw sequences of bits. >> >> While I'm still not deep enough into Ada to know how to represent the >> lists, I guess there won't be major issues, I think I can handle it >> myself (though pointers and hints would still be welcome). >> >> My question here is about how to represent the atoms in Ada. In C it >> was merely a void pointer and a size, but it seems more difficult in >> Ada because of the strong typing. Because it's up to the application >> to make sense (i.e. type) out of the raw sequences of bits in atoms, >> the S-expression library has to handle them as a sort of untyped >> memory chunk. Do you know of a way to handle that? >> >> Please correct me if I'm wrong, but my guess would be that the S- >> expression library would provide a Sexp_Atom type, which refers to the >> untyped memory chunks, and the application would have procedures to >> convert back and forth between Sexp_Atom and whatever types it >> internally uses (i.e. serialization and deserialization procedures). >> However the library would provide these procedures for the most common >> types (e.g. strings and numeric types). >> >> Though it looks like a fine Ada API (at least to my eyes), I have >> absolutely no idea about how to implement the library. How to define >> the application-opaque Sexp_Atom type? How to read Sexp_Atom objects >> from a file? How to build them from Ada types? How to write them back >> to disk? > > In Ada, you normally model blobs with > System.Storage_Elements.Storage_Array; since arrays are first-class > citizens (as opposed to C's void pointers), you do not need to carry the > length of such an array separately. Thus, a naive approach might be: > > type Sexp_Atom is access System.Storage_Elements.Storage_Array; > type Sexp; > type Sexp_Access is access Sexp; > type Sexp is record > Car : Sexp_Atom; > Cdr : Sexp_Access; > end record; > > However, the purpose of S-Expressions being to be read and written as > text, a blob may not be the most appropriate; you might be better off > with simply: > > type Sexp; > type Sexp_Access is access Sexp; > type Sexp is > Car : Ada.Strings.Unbounded.Unbounded_String; > Cdr : Sexp_Access; > Is_List : Boolean; > end record; > > To write a sexp to disk and read back, you would leverage the Ada > streams as Dmitry pointed out. > > You could then provide a generic package that serializes an arbitrary > type T back and forth to the unbounded_string. 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_expressions Enjoy. (the license is the GPLv3 or later). -- Ludovic Brenta. |