S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Dmitry A. Kazakov on 9 Aug 2010 12:11 On Mon, 09 Aug 2010 17:14:36 +0200, Georg Bauhaus wrote: > On 09.08.10 16:38, Dmitry A. Kazakov wrote: > >> I think that all these usages require different types of modular types with >> different sets of operations. So I would prefer a language extension which >> would allow me construction of such types rather than built-in ones, which >> satisfy no one. 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? 1. The membership/subset tests look even worse 2. No ranges 3. No loops 4. No case statement 5. Array aggregates as literals aren't not fun 6. No discriminants of 7. No array index of Note that array must be a view of a modular type with the modulus 2**N, but the type itself must remain scalar. >>> Writing "mod" whenever I want an expression that takes the modulus is >>> a GOOD thing. "+" should always do an add, and nothing else. >> >> Huh, modular "+" *does* add in the ring. Your "+" does not! > > How many programmers, among those without a degree in math or > in physics, know what a ring is? Why should they use the type then? > Hence, no "+" can do the "right thing", since "+" is overloaded. Most of modular types should have no + at all. There should be a readable notation for X+1 instead of infernal T'Succ(X) > A definition of the "+" operator, whose meaning(s) is (are) > stipulated to be well known, seems impossible: http://en.wikipedia.org/wiki/Abelian_group ? > Imagine a programming language that is just like Ada with > SPARK restrictions on naming. Then, throw out overloading of > predefined names, too, of "+", for example. I don't think this were possible, but basically it is what inheritance is all about. The concept of checking would be the LSP-conformity. > No more misunderstandings, then. > > But will this language be usable with beginners? Come on, children start counting before knowing anything about groups. Most of them die before they do. The language is a tool it is not a library. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Robert A Duff on 9 Aug 2010 12:35 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. 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? Perhaps Stream_Element should have been defined as exactly 8 bits. Perhaps it should have been called "Octet". - Bob
From: Georg Bauhaus on 9 Aug 2010 12:46 On 09.08.10 18:11, Dmitry A. Kazakov wrote: > On Mon, 09 Aug 2010 17:14:36 +0200, Georg Bauhaus wrote: > >> On 09.08.10 16:38, Dmitry A. Kazakov wrote: >> >>> I think that all these usages require different types of modular types with >>> different sets of operations. So I would prefer a language extension which >>> would allow me construction of such types rather than built-in ones, which >>> satisfy no one. 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? > > 1. The membership/subset tests look even worse OK. But I guess we could write inlined functions? > 2. No ranges > 3. No loops > 4. No case statement You have the index subtype at the point where you have the array type. Why not ranges, loops, and case statements? > 5. Array aggregates as literals aren't not fun Fun? > 6. No discriminants of > 7. No array index of These refer to arrays in general, not Boolean arrays as sets and, I guess, the item numbered 7 follows a general rule: Where the array type is visible, its index type is visible. (Or else, you have been too lazy and used an anonymous index type; still, you have 'first etc.) Therefore, the index type can be named without indirection, that is, via some array attribute function. (Or else, index values can be made from 'first etc.) Array access will be type checked either way. > Note that array must be a view of a modular type An array of Booleans for status fields must be a view of a modular type? I don't understand that. > with the modulus 2**N, but > the type itself must remain scalar. Uh, which type must remain scalar? >> A definition of the "+" operator, whose meaning(s) is (are) >> stipulated to be well known, seems impossible: > > http://en.wikipedia.org/wiki/Abelian_group ? That's normative ontology, not empirically justified language design ;-) I remember having seen introductory texts covering algebraic structures that use a symbol other than "+" to denote the additive operation. I think the authors have a good reason. One reason might be that they know their audience. This is an example of empirically justified use of operator symbols. When good average programmers write programs, are they structuring their data by conscious use of mathematical structures like groups? I don't think so. It is these programmers that need to know the meaning of "+". This seems vital. Example: C's "definition" of the data type int and its "+" operation demonstrates what happens if you are optimistic about mastery of C's "+" basics. I think Bob's example involving "not" of a mod 3 variable shows a related issue. (And will be included in a test of advanced Ada knowledge? ;-P) Because *even* *though* there is a precise mathematical definition (LRM) of what "not" should return, referring to some overly complex set of rules explaining the operation is hardly convincing? Consistency of the language (with itself) is only an excuse, then. Georg
From: Robert A Duff on 9 Aug 2010 12:47 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > 1. The membership/subset tests look even worse We're talking about bit maps now, right? Membership is "if Flags(X)...". Subset is "if Is_Subset(These_Flags, Those_Flags)...". The body of Is_Subset says, "(X and Y) = X". Not so horrible. > 2. No ranges > 3. No loops I don't know what you want ranges and loops for. If you really want these, you can Unchecked_Convert to integer (signed range 0..2**something). But only if something is small. > 4. No case statement Yeah, that's a shame. I'd like to have case statements on bit maps, but also on other composite types. > 5. Array aggregates as literals aren't not fun (This | That => True, The_Other => False) I agree that's ugly, but it beats 2#101#. > 6. No discriminants of I'm not sure why you'd want discriminants of bit maps, but I agree that discriminants should be more general. > 7. No array index of Unchecked_Conversion again. > Note that array must be a view of a modular type with the modulus 2**N, but > the type itself must remain scalar. All Ada compilers support: type Index is range 0..100; type Bit_Map is array (Index) of Boolean;". And this: type Bit_Map is array (Character) of Boolean;". But no Ada compilers support this: type Bit_Map is mod 2**100; > Most of modular types should have no + at all. There should be a readable > notation for X+1 instead of infernal T'Succ(X) What notation would you like? How about: function Succ (...) return ... renames T'Succ; ? - Bob
From: Robert A Duff on 9 Aug 2010 12:50
Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: > Is anything wrong with packed arrays of Booleans for status thingies? No. In fact, arrays of Booleans (packed or not) are better than modular types in that they can have an arbitrary number of bits. If you have 50 flags, and use a modular type, that's not portable -- it works in GNAT, but not all Ada compilers. And then if you change your mind and want 70 flags, you have to rewrite all the code. And if packed, they should be equally efficient. - Bob |