S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Robert A Duff on 8 Aug 2010 11:24 Natacha Kerensikova <lithiumcat(a)gmail.com> writes: > Thanks for the pointer, however I'm already afraid learning only Ada > is too much for me (I've tried with C++ and it's a language much too > complex to fit in my head (especially the STL), and I hope Ada is > simple enough), ... Ada is more complicated than C, less complicated that C++. There are also cases where Ada _seems_ less complicated. Overloading, for example. All you need to know is: - What it is. - It's allowed for subprograms and literals. (That's slightly wrong, but you don't need to care.) - The compiler resolves overloading by looking at the types of things. - If you get an ambiguity, you can resolve it in one of three ways, in decreasing order of preference: - Change the names of some things. - Specify the type of some expression using a qualified expression. - Use Package_Name.Procedure_Name notation. The actual overload resolution rules in Ada are quite complicated. Dozens of pages of text, I'd guess. But you don't need to understand them -- just wait until the compiler complains, and fix it. In C++, on the other hand, you need to understand all kinds of subtle interactions with implicit conversions, for example. So Ada's overloading rules might be as complicated as the C++ rules, but Ada _seems_ simpler, because you can safely ignore all the details. Unless you're writing an Ada compiler, of course. >...learning both Ada and AWS at the same time will > probably be way too much. Well, I'm not sure. To learn a programming language, you need to write programs, and also read programs. Jeff's point was that reading AWS will help you learn Ada, and that's probably true. By the way, I don't see anything fundamentally wrong with your s-expression plans, with s-expressions containing raw arrays-of-octets -- especially since you say you already have a lot of stuff using s-exprs. You can layer on top of that less-general but more-typed abstractions, probably using generics. - Bob
From: Robert A Duff on 8 Aug 2010 11:34 Natacha Kerensikova <lithiumcat(a)gmail.com> writes: > (probably Integer mod 2**16 or something like that). There's no such thing as "Integer mod 2**16". "mod ..." is how you declare an unsigned integer type (called "modular type" in Ada), and "range ..." is how you declare a signed integer type. Integer is a predefined signed integer type. It's range is not portable, so if you care about that, it should be avoided. It's a good idea to declare your own integer types -- different types for different purposes. For example, if you have an array of indexes into another array, using different index types for the two arrays will often make the code readable -- it will be obvious that (say) X is intended for indexing into the outer array. Modular types are evil, and should usually be avoided. You might want modular types when interfacing with C code, but don't use them just because you happen to have no negative numbers. For example, I would usually (not always!) prefer this: type Octet is range 0..2**8-1; -- signed over this: type Octet is mod 2**8; -- unsigned The index type of an unconstrained array should (almost) never be modular. - Bob
From: Dmitry A. Kazakov on 8 Aug 2010 14:24 On Sun, 08 Aug 2010 11:34:23 -0400, Robert A Duff wrote: > Modular types are evil, and should usually be avoided. They aren't, modular arithmetic is. I wished to be able to define a modular types without +,-,*,/, and, or, xor, and have a more decent notation for S'Succ and S'Pred. > The index type of an unconstrained array should (almost) never > be modular. That is again not their fault. If a subtype of a modular type were modular, e,g, type T is mod 256; subtype S is T range 2..10; X : S := 10; begin X := X + 1; -- The result is 2! then they could be used as indices. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Robert A Duff on 8 Aug 2010 16:03 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Sun, 08 Aug 2010 11:34:23 -0400, Robert A Duff wrote: > >> Modular types are evil, and should usually be avoided. > > They aren't, modular arithmetic is. Hmm. Implicit modular arithmetic is evil. I have no problem with expressions like "X mod N". >...I wished to be able to define a modular > types without +,-,*,/, and, or, xor, and have a more decent notation for > S'Succ and S'Pred. > >> The index type of an unconstrained array should (almost) never >> be modular. > > That is again not their fault. If a subtype of a modular type were modular, > e,g, > > type T is mod 256; > subtype S is T range 2..10; > > X : S := 10; > begin > X := X + 1; -- The result is 2! 2 factorial? ;-) For scalars, the primitive operations mostly don't know the subtype bounds -- they are operations of the type. So this wouldn't fit into Ada well. > ...then they could be used as indices. The problem I was alluding to is that if you have an unconstrained array type, sooner or later you might have an empty one. So you want bounds 0..-1, but -1 wraps around. Same thing with a "for" loop that goes from T'First up to something. If 2..10 wrapped around, then you'd want range 2..1, which has the same problem. Did I mention that modular types are my least favorite feature of Ada? ;-) - Bob
From: Jeffrey Carter on 8 Aug 2010 16:11
On 08/08/2010 03:26 AM, Simon Wright wrote: > I'd disagree with Jeffrey here. > > Nothing wrong with stating at the bottom! especially when you already > know that the component you're looking at is likely to be useful and to > fit into *your* way of thinking about things. Your plan already has > higher-level abstractions, so that if you get to the next layer up and > want to change your lowest layer (if only for experimentation's sake) > you will be able to do so. > > Lots of people round here are responsible for component libraries at > various levels of abstraction which they've developed for their own > purposes and then pushed out to the community in the hope they'll help > someone else. As someone who is responsible for a library, I not sure we disagree. Certainly when one gets to the point of deciding on a representation, one should implement one's choice in a reusable manner if possible, or reuse an existing library; often the existence of a library will be an important factor in choosing a representation. Where we may disagree is that I don't think one should begin a project such as this by choosing a representation. -- Jeff Carter "I wave my private parts at your aunties." Monty Python & the Holy Grail 13 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |