S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Dmitry A. Kazakov on 9 Aug 2010 16:40 On Mon, 09 Aug 2010 18:46:27 +0200, Georg Bauhaus wrote: > When good average programmers write programs, are they > structuring their data by conscious use of mathematical > structures like groups? I don't think so. They do it unconsciously. It is no matter if we do it willingly or not, there is only one right way. > 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 don't see your point. It is broken in C because it contradicts to the mathematical meaning of. So what do you propose? To keep it broken? Because people better understand broken stuff? They don't. > 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. Nope, "not" is just broken for mod 3. It is a lattice operation, it has nothing to do with rings. The problem with modular types is that one tried to build a submarine which could fly. It sails like an aircraft and flies like a ship. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Robert A Duff on 9 Aug 2010 17:30 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > OK, but it is not modular, it is natural. And it is just a different case > where modular types should not be used in first place, like size_t. Right, the whole point of this part of the discussion is: I was trying to show how Ada's signed integer types could be improved to cover cases where Ada's modular types are commonly used. > This is will be a source of errors like forgetting mod or specifying wrong > modulus. The idea of modular types is to prevent such errors. I see that point, which was also made by others. I at least half-agree with it. > Yes, but what I want will never become Ada, so I prefer that minimum I can > get. (:-)) ;-) - Bob
From: Robert A Duff on 9 Aug 2010 17:34 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >>> 2. No ranges >>> 3. No loops >> >> I don't know what you want ranges and loops for. > > A subset of flags. E.g. Critical_Errors, Warnings, Any_Error. I don't understand this part. If subrange of a modular type used as a bit map is not a coherent subset of the flags. > Yes, it is a type property that the domain is a set of identifiable values, > in fact, some mapping to an enumeration. > > The language should provide means to implement this interface with any > type. E.g. why I cannot specify this interface for String to be able to > write: > > case Get_Token is > when "type" => ... > when "package" => ... > when others => raise Syntax_Error; > end case; It would be nice. >> But no Ada compilers support this: >> >> type Bit_Map is mod 2**100; > > Why not? It is not that difficult to implement mod 2**100 or range > -2**1_000_000..2**1_000_000+1. I think the standard should require it on > any hardware. I agree. But you and I are in a small minority here! The frustrating thing to me is that every Ada compiler must support arbitrary-range integer arithmetic at compile time, but can't make that available in a portable way at run time. - Bob
From: Georg Bauhaus on 9 Aug 2010 18:21 Dmitry A. Kazakov wrote: > there is only one right way. (There is one right way per person. Some agree on the right way. Even those who believe(!) in the one right way don't know(!) for sure ... ;-) > ["+"] is broken in C because it contradicts to the > mathematical meaning of. The mathematical meaning of "+" is ambiguous or context dependent. It depends on the definitions of "+" etc. Programmers usually pick one meaning of "+", which then turns out to be the traditional mathematical preconception. There is no way to fix preconceptions other than through shock, pain, and learning. The thing to be unlearned has a name: "+". > So what do you propose? To keep it broken? Because > people better understand broken stuff? They don't. Use operator symbols that clearly separate: - traditional mathematical addition - computer addition If you don't keep the concepts apart visually, programmers see "+", see something seemingly familiar, and will think that "+" means "+". But "+" doesn't mean "+", and this causes all kinds of problems. Expensive problems. Even more so when "+" is considered magic and is thus admired. C does use "+" in all sorts of places, overloading "+" for arithmetic and pointers. You can't do anything substantial in C without "+", explicitly or implicitly. int f() {} int (*g)() = f + 4; int main() { return g(); } I'm sure someone familiar with C will find it easy to explain why this is a harmless program in most implementations of C... I believe APL's intent shows a way to rectify the imprecise operator names issue. Georg
From: Jeffrey Carter on 9 Aug 2010 18:29
On 08/09/2010 02:34 PM, Robert A Duff wrote: > > The frustrating thing to me is that every Ada compiler must support > arbitrary-range integer arithmetic at compile time, but can't make > that available in a portable way at run time. Yes. And arbitrary-range rational arithmetic. Every compiler that supports the container library has a hash table and some sort of searchable structure (balanced tree, skip list) implementation. None of these are portably available to developers. This is a mistake, IMO. -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |