From: Natacha Kerensikova on
On Aug 8, 11:08 pm, Robert A Duff <bobd...(a)>
> "Dmitry A. Kazakov" <mail...(a)> 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,
From: Georg Bauhaus on
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?


From: Natacha Kerensikova on
On Aug 9, 5:14 pm, Georg Bauhaus <rm.dash-bauh...(a)>
> 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?

From: Natacha Kerensikova on
On Aug 9, 5:40 pm, Simon Wright <si...(a)> wrote:
> Natacha Kerensikova <lithium...(a)> 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,
From: Ludovic Brenta on
Ludovic Brenta <ludovic(a)> writes on comp.lang.ada:
> Natacha Kerensikova <lithiumcat(a)> 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:

Enjoy. (the license is the GPLv3 or later).

Ludovic Brenta.
First  |  Prev  |  Next  |  Last
Pages: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Prev: GPRbuild compatibility
Next: Irony?