* Address and bit mask @ 2011-08-29 15:46 milouz 2011-08-29 16:06 ` Martin 2011-08-29 19:41 ` Ludovic Brenta 0 siblings, 2 replies; 64+ messages in thread From: milouz @ 2011-08-29 15:46 UTC (permalink / raw) How do you make a binary operation (and, or, etc.) in Ada on an Address type in a rather portable way ? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 15:46 Address and bit mask milouz @ 2011-08-29 16:06 ` Martin 2011-08-29 16:33 ` milouz 2011-08-29 19:41 ` Ludovic Brenta 1 sibling, 1 reply; 64+ messages in thread From: Martin @ 2011-08-29 16:06 UTC (permalink / raw) On Aug 29, 4:46 pm, milouz <a.micheli...@gmail.com> wrote: > How do you make a binary operation (and, or, etc.) in Ada on an > Address type in a rather portable way ? To start with, check out package System.Storage_Elements. It at least has To_Address/To_Integer subprograms. Size/range of addresses are rather target dependent, so I'm curious as to what you wish to make 'portable'?... -- Martin ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 16:06 ` Martin @ 2011-08-29 16:33 ` milouz 2011-08-29 17:47 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: milouz @ 2011-08-29 16:33 UTC (permalink / raw) > To start with, check out package System.Storage_Elements. It at least > has To_Address/To_Integer subprograms. As far as I understand, your solution is to convert the address in address_integer, manipulating it, and then converting it in address. And all that stuff is because Address type is defined as private. Am I right ? > Size/range of addresses are rather target dependent, so I'm curious as > to what you wish to make 'portable'?... I mean a solution that works with the Address type without the need to redefine everything. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 16:33 ` milouz @ 2011-08-29 17:47 ` Dmitry A. Kazakov 2011-08-29 17:54 ` Martin 2011-08-29 18:46 ` tmoran 2 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-29 17:47 UTC (permalink / raw) On Mon, 29 Aug 2011 09:33:29 -0700 (PDT), milouz wrote: >> To start with, check out package System.Storage_Elements. It at least >> has To_Address/To_Integer subprograms. > > As far as I understand, your solution is to convert the address in > address_integer, manipulating it, and then converting it in address. > And all that stuff is because Address type is defined as private. > Am I right ? There is Storage_Offset type in System.Storage_Elements. Address arithmetic is most likely to be done on the offsets to some definite address, for example, alignment computations. Bit-wise operations are either meaningless or machine-specific. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 16:33 ` milouz 2011-08-29 17:47 ` Dmitry A. Kazakov @ 2011-08-29 17:54 ` Martin 2011-08-29 18:46 ` tmoran 2 siblings, 0 replies; 64+ messages in thread From: Martin @ 2011-08-29 17:54 UTC (permalink / raw) On Aug 29, 5:33 pm, milouz <a.micheli...@gmail.com> wrote: > > To start with, check out package System.Storage_Elements. It at least > > has To_Address/To_Integer subprograms. > > As far as I understand, your solution is to convert the address in > address_integer, manipulating it, and then converting it in address. > And all that stuff is because Address type is defined as private. > Am I right ? > > > Size/range of addresses are rather target dependent, so I'm curious as > > to what you wish to make 'portable'?... > > I mean a solution that works with the Address type without the need to > redefine everything. Maybe, without know what you actually want to do, it's hard to say. I'd definitely be littering the code that did the manipulation with all sorts of "pragma Assert"s. Things under System.* are, well, system specific - the language makes no guarantee about the format of the integer address (signed or modular?). Perhaps you 'know' that 32-bit addresses are all you are ever going to use - so you could Assert that knowledge. It'll come in handy the day someone else decides to port it to a 64-bit cpu. -- Martin ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 16:33 ` milouz 2011-08-29 17:47 ` Dmitry A. Kazakov 2011-08-29 17:54 ` Martin @ 2011-08-29 18:46 ` tmoran 2 siblings, 0 replies; 64+ messages in thread From: tmoran @ 2011-08-29 18:46 UTC (permalink / raw) > As far as I understand, your solution is to convert the address in > address_integer, manipulating it, and then converting it in address. > And all that stuff is because Address type is defined as private. > Am I right ? > > > Size/range of addresses are rather target dependent, so I'm curious as > > to what you wish to make 'portable'?... > > I mean a solution that works with the Address type without the need to > redefine everything. "New_Paint_Color := Old_Paint_Color + 3;" makes no sense in general, though in certain circumstances adding 3 to the numeric representation of a color may make a great deal of sense. Similarly, ANDing two addresses does not in general make any sense, but sometimes ANDing their bitwise representation may be just the thing. Ada tries to operate at the level of abstraction where a color is a color, not a number, and an address is an address, not a number. The compiler will catch abstraction level mismatches. If you want to do something at a lower abstraction level, you have to tell the compiler you are changing levels. That's what System.Storage_Elements is for. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 15:46 Address and bit mask milouz 2011-08-29 16:06 ` Martin @ 2011-08-29 19:41 ` Ludovic Brenta 2011-08-29 19:54 ` Adam Beneschan 1 sibling, 1 reply; 64+ messages in thread From: Ludovic Brenta @ 2011-08-29 19:41 UTC (permalink / raw) milouz writes: > How do you make a binary operation (and, or, etc.) in Ada on an > Address type in a rather portable way ? You don't. Addresses are not portable at all, not even "rather". I'm curious. Why do you need bitwise operations on addresses? I did a lot of *eminently non-portable* bitwise operations on addresses when I worked in avionics, so I know when to do them and when not to. For the curious, the operations were in the low-level device driver for a FLASH device, and in a bootloader. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 19:41 ` Ludovic Brenta @ 2011-08-29 19:54 ` Adam Beneschan 2011-08-30 9:14 ` milouz 0 siblings, 1 reply; 64+ messages in thread From: Adam Beneschan @ 2011-08-29 19:54 UTC (permalink / raw) On Aug 29, 12:41 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > milouz writes: > > How do you make a binary operation (and, or, etc.) in Ada on an > > Address type in a rather portable way ? > > You don't. Addresses are not portable at all, not even "rather". > > I'm curious. Why do you need bitwise operations on addresses? The only case that makes to me is checking the low-order N bits (N=2 or 3 or something small like that) to make sure an address meets certain alignment requirements. But System.Storage_Elements already has a "mod" operation that works quite nicely for that. Perhaps that's what the OP is looking for...? -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-29 19:54 ` Adam Beneschan @ 2011-08-30 9:14 ` milouz 2011-08-30 10:34 ` Ludovic Brenta ` (4 more replies) 0 siblings, 5 replies; 64+ messages in thread From: milouz @ 2011-08-30 9:14 UTC (permalink / raw) Ok, thank you very much for all your answers, but I'm not really more advanced. Let me summarize : - my question was about address arithmetic (howto ?) - Some fellows gave me cues about the use of the System.Storage_Elements, but without gaving any concrete example. - Some others just wandered about the need of doing address arithmetic. Hum... well... I still do not know how to do some simple arithmetic with address. So, let me give you an example in C : p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); How do you write that in Ada ? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 9:14 ` milouz @ 2011-08-30 10:34 ` Ludovic Brenta 2011-08-30 10:58 ` Ludovic Brenta 2011-08-30 14:52 ` Adam Beneschan 2011-08-30 10:40 ` Simon Wright ` (3 subsequent siblings) 4 siblings, 2 replies; 64+ messages in thread From: Ludovic Brenta @ 2011-08-30 10:34 UTC (permalink / raw) milouz wrote on comp.lang.ada: > Ok, thank you very much for all your answers, but I'm not really more > advanced. Let me summarize : > > - my question was about address arithmetic (howto ?) > - Some fellows gave me cues about the use of the > System.Storage_Elements, but without gaving any concrete example. > - Some others just wandered about the need of doing address > arithmetic. > > Hum... well... I still do not know how to do some simple arithmetic > with address. So, let me give you an example in C : > > p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); > > How do you write that in Ada ? You don't. You declare an array of characters, specify that each character takes up ALIGN_MASK*Storage_Unit bits and that the array is aligned on an ALIGN_MASK boundary. No need for address arithmetic or bitwise operations. declare Alignment : constant := 2**3; -- bytes type P_T is array (Positive range <>) of Character; for P_T'Alignment use Alignment; -- storage_elements for P_T'Component_Size use Alignment * System.Storage_Unit; -- bits P : P_T (1 .. Number_Of_Elements_In_The_Array); -- if P starts at a specific address, you say so: for P'Address use The_Starting_Address_Of_P; begin for Index in P'Range loop P (Index) := Foo; end loop; end; The above is not strictly equivalent to your C example; it is much better: - it says what it does (as opposed to how it does it); - it has bounds checking on the array such that you cannot read or write outside the array; - it allows you to pass the array as a parameter to subprograms, as opposed to a pointer to the array (worry not, the compiler will pass by address behind the scenes) If the extremely rare case where you really, really must do address arithmetic, you still don't need bitwise operations on addresses. You simply use System.Storage_Elements like so: function Succ (A : in System.Address) return System.Address is Alignment : constant Storage_Offset := 2**3; use System.Storage_Elements; begin return (A + Alignment) mod Alignment; -- note: "+" and "mod" are in System.Storage_Elements end Increment; -- Ludovic Brenta. Our unique strategic thinking inspires the team players. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 10:34 ` Ludovic Brenta @ 2011-08-30 10:58 ` Ludovic Brenta 2011-08-30 12:44 ` Georg Bauhaus 2011-08-30 14:52 ` Adam Beneschan 1 sibling, 1 reply; 64+ messages in thread From: Ludovic Brenta @ 2011-08-30 10:58 UTC (permalink / raw) Ludovic Brenta wrote: > milouz wrote on comp.lang.ada: >> p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); >> How do you write that in Ada ? > > You don't. Please take that seriously. Whenever I see this kind of thing in an Ada program during formal code review, I reject it outright. C is a *bad* language. It does not allow you to specify an alignment or the size of your elements, so it forces you to do address arithmetic. Ada does not have these limitations, so you can say what you are doing. (Also: the reason why you simulate the modulo operator (% in C) with two bitwise operations, bitwise and and bitwise not, escapes me). Transliterating a bad C program into the Ada syntax results in a bad "C in Ada" program; hence the rejection and the very formal "you don't". Please do not take the above as an attempt to disparage you; what you wrote is perfectly idiomatic C. I only wanted to point out that even perfectly idiomatic C is still bad. That's not your fault; you are simply the victim of bad language design. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 10:58 ` Ludovic Brenta @ 2011-08-30 12:44 ` Georg Bauhaus 2011-08-30 14:04 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-30 12:44 UTC (permalink / raw) On 30.08.11 12:58, Ludovic Brenta wrote: > C is a *bad* language. Please don't say C is a bad language. It isn't, in many ways. It *does* require very good and very careful programmers; alas, more of these than think of themselves as being very good and very careful. *This* is the bad thing. Technical inferiorities and natural obfuscation apply, forming social classes, igniting wars, preventing technical talk. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 12:44 ` Georg Bauhaus @ 2011-08-30 14:04 ` Dmitry A. Kazakov 2011-08-30 16:12 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-30 14:04 UTC (permalink / raw) On Tue, 30 Aug 2011 14:44:20 +0200, Georg Bauhaus wrote: > On 30.08.11 12:58, Ludovic Brenta wrote: > >> C is a *bad* language. > > Please don't say C is a bad language. It isn't, in many ways. > > It *does* require very good and very careful programmers; > alas, more of these than think of themselves as being very > good and very careful. *This* is the bad thing. I see. Murder is not bad. That something dies is bad, not the deed itself. This kind of logic? C is bad (worse than the language X) simply because it is less suitable for programming (read: software developing). Of course, C might be good (better than X) for anything else, but that is irrelevant. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 14:04 ` Dmitry A. Kazakov @ 2011-08-30 16:12 ` Georg Bauhaus 2011-08-30 16:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-30 16:12 UTC (permalink / raw) On 30.08.11 16:04, Dmitry A. Kazakov wrote: > On Tue, 30 Aug 2011 14:44:20 +0200, Georg Bauhaus wrote: > >> On 30.08.11 12:58, Ludovic Brenta wrote: >> >>> C is a *bad* language. >> >> Please don't say C is a bad language. It isn't, in many ways. >> >> It *does* require very good and very careful programmers; >> alas, more of these than think of themselves as being very >> good and very careful. *This* is the bad thing. > > I see. Murder is not bad. That something dies is bad, not the deed itself. > This kind of logic? No, a double edged dagger with flexible handle might be something many find natural, good for extreme gardening maybe. If one group of programmers have learned to like some tool, even have written a popular OS using the tool, if Knuth uses the tool, what will they say, and think about us, if we tell them: "Your choice of tool is bad!" We loose, won't we? But not on technical grounds. http://www.electronicsweekly.com/blogs/engineering-design-problems/2009/02/impossible-objects-2-electric.html http://vimeo.com/2234590 Per Brinch Hansen, when he explained how Java's concurrency primitives are defective, said "bad", too. And more things. He found a style in his critique to the effect that the crowd ... ignored his critique. At best. > C is bad (worse than the language X) simply because it is less suitable for > programming (read: software developing). Of course, C might be good (better > than X) for anything else, but that is irrelevant. The parentheses in particular will work a lot better if restricted to single technical effects, I think; "software developing" can only imply things, lots of unnamed things. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 16:12 ` Georg Bauhaus @ 2011-08-30 16:59 ` Dmitry A. Kazakov 0 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-30 16:59 UTC (permalink / raw) On Tue, 30 Aug 2011 18:12:47 +0200, Georg Bauhaus wrote: > On 30.08.11 16:04, Dmitry A. Kazakov wrote: >> On Tue, 30 Aug 2011 14:44:20 +0200, Georg Bauhaus wrote: >> >>> On 30.08.11 12:58, Ludovic Brenta wrote: >>> >>>> C is a *bad* language. >>> >>> Please don't say C is a bad language. It isn't, in many ways. >>> >>> It *does* require very good and very careful programmers; >>> alas, more of these than think of themselves as being very >>> good and very careful. *This* is the bad thing. >> >> I see. Murder is not bad. That something dies is bad, not the deed itself. >> This kind of logic? > > No, a double edged dagger with flexible handle might be something many > find natural, good for extreme gardening maybe. That does not make it a good grass-cutter. There are multiple ways to verify that experimentally at any desired level of scrutiny... > If one group of programmers > have learned to like some tool, even have written a popular OS using the > tool, if Knuth uses the tool, what will they say, and think about us, > if we tell them: "Your choice of tool is bad!" We loose, won't we? We did it already. But that does not change facts. When perception is incoherent to the reality, what are you going to fix? The software industry and the education system long ago decided to fix the reality. They can afford this, because others are paying for that. > But not on technical grounds. > > http://www.electronicsweekly.com/blogs/engineering-design-problems/2009/02/impossible-objects-2-electric.html Is it an example of a good hammer? >> C is bad (worse than the language X) simply because it is less suitable for >> programming (read: software developing). Of course, C might be good (better >> than X) for anything else, but that is irrelevant. > > The parentheses in particular will work a lot better if restricted > to single technical effects, I think; "software developing" > can only imply things, lots of unnamed things. Hmm, any word imply things it means, so what? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 10:34 ` Ludovic Brenta 2011-08-30 10:58 ` Ludovic Brenta @ 2011-08-30 14:52 ` Adam Beneschan 1 sibling, 0 replies; 64+ messages in thread From: Adam Beneschan @ 2011-08-30 14:52 UTC (permalink / raw) On Aug 30, 3:34 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > If the extremely rare case where you really, really must do address > arithmetic, you still don't need bitwise operations on addresses. You > simply use System.Storage_Elements like so: > > function Succ (A : in System.Address) return System.Address is > Alignment : constant Storage_Offset := 2**3; > use System.Storage_Elements; > begin > return (A + Alignment) mod Alignment; > -- note: "+" and "mod" are in System.Storage_Elements > end Increment; "mod" won't return a System.Address. (Not to mention that you can't end a function Succ with "end Increment", but now I'm just being picky.) Here's a function that rounds A up to the next multiple of Alignment (the result could equal A): function Align_Up (A : in System.Address) return System.Address is Alignment : constant Storage_Offset := 2**3; B : System.Address; use System.Storage_Elements; begin B := A + (Alignment - 1); return B - (B mod Alignment); -- the latter has the effect of zeroing out the low bits of B, like B & ~ALIGN_MASK end Align_Up; -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 9:14 ` milouz 2011-08-30 10:34 ` Ludovic Brenta @ 2011-08-30 10:40 ` Simon Wright 2011-08-30 10:44 ` Simon Wright 2011-08-30 15:20 ` tmoran 2011-08-30 12:35 ` Georg Bauhaus ` (2 subsequent siblings) 4 siblings, 2 replies; 64+ messages in thread From: Simon Wright @ 2011-08-30 10:40 UTC (permalink / raw) milouz <a.michelizza@gmail.com> writes: > Hum... well... I still do not know how to do some simple arithmetic > with address. So, let me give you an example in C : > > p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); > > How do you write that in Ada ? Perhaps you could achieve that by using the Alignment attribute? ------------------------------ with Ada.Text_IO; With System.Storage_Elements; procedure Alignment is type Aligned_Char is new Character; for Aligned_Char'Alignment use 16#1000#; type Character_P is access Character; type Aligned_Char_P is access Aligned_Char; C : constant Character_P := new Character'('c'); A : constant Aligned_Char_P := new Aligned_Char'('a'); package Address_IO is new Ada.Text_IO.Modular_IO (System.Storage_Elements.Integer_Address); begin Ada.Text_IO.Put ("Address of allocated Character:"); Address_IO.Put (System.Storage_Elements.To_Integer (C.all'Address), Base => 16); Ada.Text_IO.New_Line; Ada.Text_IO.Put ("Address of allocated Character:"); Address_IO.Put (System.Storage_Elements.To_Integer (A.all'Address), Base => 16); Ada.Text_IO.New_Line; end Alignment; ------------------------------ gnatmake -gnatwa alignment.adb gcc -c -gnatwa alignment.adb alignment.adb:6:35: warning: suspiciously large alignment specified for "Aligned_Char" gnatbind -x alignment.ali gnatlink alignment.ali ------------------------------ $ ~/tmp/alignment Address of allocated Character: 16#1092008F0# Address of allocated Aligned_Char: 16#7F9164001000# $ ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 10:40 ` Simon Wright @ 2011-08-30 10:44 ` Simon Wright 2011-08-30 15:20 ` tmoran 1 sibling, 0 replies; 64+ messages in thread From: Simon Wright @ 2011-08-30 10:44 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > type Aligned_Char is new Character; > for Aligned_Char'Alignment use 16#1000#; or even type Aligned_Char is new Character with Alignment => 16#1000#; with the -gnat12 switch to enable the new Ada2012 aspect feature. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 10:40 ` Simon Wright 2011-08-30 10:44 ` Simon Wright @ 2011-08-30 15:20 ` tmoran 2011-08-30 16:08 ` milouz 2011-08-30 16:32 ` Simon Wright 1 sibling, 2 replies; 64+ messages in thread From: tmoran @ 2011-08-30 15:20 UTC (permalink / raw) > for Aligned_Char'Alignment use 16#1000#; > ... > alignment.adb:6:35: warning: suspiciously large alignment specified for "Aligned_Char" I don't see it right now, but didn't someone say we want 8 byte alignment, ie 2#1000#, not 16#1000#? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 15:20 ` tmoran @ 2011-08-30 16:08 ` milouz 2011-08-30 16:45 ` Georg Bauhaus 2011-08-30 19:37 ` Address and bit mask Martin 2011-08-30 16:32 ` Simon Wright 1 sibling, 2 replies; 64+ messages in thread From: milouz @ 2011-08-30 16:08 UTC (permalink / raw) Thank you very much for all your answers ! They are all very detailed and I feel that I have a better grasp of how to program with Ada now. But something still puzzles me... I'm ok when Adam B. says: > asking "How do I write this C code in Ada" is the WRONG approach. But, let me develop... In C, it's rather easy to know how to do something because 1/ the langage is so simple and 2/ there are some many helpful resources (K&R, glibc source code or whatever else, man pages, Stevens's books...). I talk here about C but it's rather the same with Python, Perl, C++ or Java. In Ada, I found nothing similar and even finding howto do a kind of 'printf("%x"...)'... hum, sorry... displaying an Integer in hexa, is difficult. The ARM is a load of 800 pages with no example (it's a reference manual. how would learn C by reading ISO/CEI 9899:1999 ?). J.Barnes book might be great but... waiting 571 pages to learn how to display "hello, world" on a screen is a bit discouraging. Don't get me wrong, I'm convinced Ada is great. But what is the proper way to learn Ada ? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 16:08 ` milouz @ 2011-08-30 16:45 ` Georg Bauhaus 2011-08-30 19:31 ` Adam Beneschan 2011-08-30 19:37 ` Address and bit mask Martin 1 sibling, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-30 16:45 UTC (permalink / raw) On 30.08.11 18:08, milouz wrote: > But, let me develop... > In C, it's rather easy to know how to do something because 1/ the > langage is so simple and 2/ there are some many helpful resources (The C language is perceivied to be simple, when it isn't: what's the C type of 60*60*24? How do size_t and unsigned long int differ? This is one reason why there are so many CVEs...) Ada learning material: http://www.it.bton.ac.uk/staff/je/adacraft/contents.htm http://www.adaic.org/learn/materials/ A K&R of Ada, with extensions for Ada 95 and Ada 2005: http://archive.adaic.com/standards/83rat/html/ratl-03.html http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-p1-2.html http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-TTL.html An introduction for programmers: http://www.adaic.org/wp-content/uploads/2010/05/Ada-Distilled-10-Sept-2009.pdf > In Ada, I found nothing similar and even finding howto do a kind of > 'printf("%x"...)'... hum, sorry... displaying an Integer in hexa, is > difficult. How do you print an int in duodecimal (base 12) in C? :-) Base 16 and others in Ada: with Ada.Text_IO; procedure Int_Based is use Ada; package Duodec_IO is new Text_IO.Integer_IO (Natural); X : Natural := 123; begin Duodec_IO.Put (X, Base => 3); Duodec_IO.Put (X, Base => 8); Duodec_IO.Put (X, Base => 10); Duodec_IO.Put (X, Base => 12); Duodec_IO.Put (X, Base => 16); Text_IO.New_Line; end Int_Based; ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 16:45 ` Georg Bauhaus @ 2011-08-30 19:31 ` Adam Beneschan 2011-08-30 19:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Adam Beneschan @ 2011-08-30 19:31 UTC (permalink / raw) On Aug 30, 9:45 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > > In Ada, I found nothing similar and even finding howto do a kind of > > 'printf("%x"...)'... hum, sorry... displaying an Integer in hexa, is > > difficult. > > How do you print an int in duodecimal (base 12) in C? :-) > > Base 16 and others in Ada: > > with Ada.Text_IO; > > procedure Int_Based is > use Ada; > > package Duodec_IO is > new Text_IO.Integer_IO (Natural); > > X : Natural := 123; > begin > Duodec_IO.Put (X, Base => 3); > Duodec_IO.Put (X, Base => 8); > Duodec_IO.Put (X, Base => 10); > Duodec_IO.Put (X, Base => 12); > Duodec_IO.Put (X, Base => 16); > Text_IO.New_Line; > end Int_Based; I realize you had a smiley in there, but showing how easy it is to do something that nobody is likely to want to do in a million (12#402854#) years isn't really the best advertisement we can come up with for the language. I actually think Ada has a bit of a weakness in this regard. The ability to output and/or create strings that have data interpolated in them is useful, but doing so with Ada is somewhat clunky. Ada does provide a string concatenation function, which C doesn't have, and that could help, except that (1) there's no *function* defined in Ada that returns the image of an integer in a given base (and if there were, I'd want it to have options to control whether the 16#...# were present or not, whether letters were in upper or lower case, and whether and how far we add leading zeroes), and (2) the 'Image attribute function on integer types has the annoying problem of the extra space at the front of nonnegative integers. With those fixed, it would eliminate an objection I'm sure other C programmers trying to use Ada have run into. Of course, C's printf() is really a terrible solution to the problem, mainly because you have to specify in the format string what the length of the integer data is (short, long, long long), and if you get it wrong and the format specifiers don't match the variable arguments---woe, woe, woe. (And that problem is still minor compared to what happens if you get the length wrong in scanf(), as I've done in the past.) -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 19:31 ` Adam Beneschan @ 2011-08-30 19:56 ` Dmitry A. Kazakov 2011-08-31 6:16 ` The simple Image issue (was: Address and bit mask) Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-30 19:56 UTC (permalink / raw) On Tue, 30 Aug 2011 12:31:55 -0700 (PDT), Adam Beneschan wrote: > I actually think Ada has a bit of a weakness in this regard. The > ability to output and/or create strings that have data interpolated in > them is useful, but doing so with Ada is somewhat clunky. Ada does > provide a string concatenation function, which C doesn't have, and > that could help, except that (1) there's no *function* defined in Ada > that returns the image of an integer in a given base (and if there > were, I'd want it to have options to control whether the 16#...# were > present or not, whether letters were in upper or lower case, and > whether and how far we add leading zeroes), and (2) the 'Image > attribute function on integer types has the annoying problem of the > extra space at the front of nonnegative integers. With those fixed, > it would eliminate an objection I'm sure other C programmers trying to > use Ada have run into. The most annoying is that you have to specify the [sub]type T'Image(X). It should have been X'Image or Image(X). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* The simple Image issue (was: Address and bit mask) 2011-08-30 19:56 ` Dmitry A. Kazakov @ 2011-08-31 6:16 ` Georg Bauhaus 2011-08-31 14:44 ` The simple Image issue Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 6:16 UTC (permalink / raw) On 30.08.11 21:56, Dmitry A. Kazakov wrote: > On Tue, 30 Aug 2011 12:31:55 -0700 (PDT), Adam Beneschan wrote: > >> I actually think Ada has a bit of a weakness in this regard. The >> ability to output and/or create strings that have data interpolated in >> them is useful, but doing so with Ada is somewhat clunky. Ada does >> provide a string concatenation function, which C doesn't have, and >> that could help, except that (1) there's no *function* defined in Ada >> that returns the image of an integer in a given base (and if there >> were, I'd want it to have options to control whether the 16#...# were >> present or not, whether letters were in upper or lower case, and >> whether and how far we add leading zeroes), and (2) the 'Image >> attribute function on integer types has the annoying problem of the >> extra space at the front of nonnegative integers. With those fixed, >> it would eliminate an objection I'm sure other C programmers trying to >> use Ada have run into. > > The most annoying is that you have to specify the [sub]type T'Image(X). It > should have been X'Image or Image(X). In which way would you change T'Value for symmetry? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 6:16 ` The simple Image issue (was: Address and bit mask) Georg Bauhaus @ 2011-08-31 14:44 ` Dmitry A. Kazakov 2011-08-31 15:36 ` Georg Bauhaus 2011-08-31 15:53 ` The simple Image issue Hyman Rosen 2011-08-31 16:08 ` The simple Image issue (was: Address and bit mask) Adam Beneschan 2 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 14:44 UTC (permalink / raw) On Wed, 31 Aug 2011 08:16:35 +0200, Georg Bauhaus wrote: > On 30.08.11 21:56, Dmitry A. Kazakov wrote: >> On Tue, 30 Aug 2011 12:31:55 -0700 (PDT), Adam Beneschan wrote: >> >>> I actually think Ada has a bit of a weakness in this regard. The >>> ability to output and/or create strings that have data interpolated in >>> them is useful, but doing so with Ada is somewhat clunky. Ada does >>> provide a string concatenation function, which C doesn't have, and >>> that could help, except that (1) there's no *function* defined in Ada >>> that returns the image of an integer in a given base (and if there >>> were, I'd want it to have options to control whether the 16#...# were >>> present or not, whether letters were in upper or lower case, and >>> whether and how far we add leading zeroes), and (2) the 'Image >>> attribute function on integer types has the annoying problem of the >>> extra space at the front of nonnegative integers. With those fixed, >>> it would eliminate an objection I'm sure other C programmers trying to >>> use Ada have run into. >> >> The most annoying is that you have to specify the [sub]type T'Image(X). It >> should have been X'Image or Image(X). > > In which way would you change T'Value for symmetry? "123"'Value or Value("123"), of course -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 14:44 ` The simple Image issue Dmitry A. Kazakov @ 2011-08-31 15:36 ` Georg Bauhaus 2011-08-31 15:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 15:36 UTC (permalink / raw) On 31.08.11 16:44, Dmitry A. Kazakov wrote: > On Wed, 31 Aug 2011 08:16:35 +0200, Georg Bauhaus wrote: > >> On 30.08.11 21:56, Dmitry A. Kazakov wrote: >>> On Tue, 30 Aug 2011 12:31:55 -0700 (PDT), Adam Beneschan wrote: >>> >>>> I actually think Ada has a bit of a weakness in this regard. The >>>> ability to output and/or create strings that have data interpolated in >>>> them is useful, but doing so with Ada is somewhat clunky. Ada does >>>> provide a string concatenation function, which C doesn't have, and >>>> that could help, except that (1) there's no *function* defined in Ada >>>> that returns the image of an integer in a given base (and if there >>>> were, I'd want it to have options to control whether the 16#...# were >>>> present or not, whether letters were in upper or lower case, and >>>> whether and how far we add leading zeroes), and (2) the 'Image >>>> attribute function on integer types has the annoying problem of the >>>> extra space at the front of nonnegative integers. With those fixed, >>>> it would eliminate an objection I'm sure other C programmers trying to >>>> use Ada have run into. >>> >>> The most annoying is that you have to specify the [sub]type T'Image(X). It >>> should have been X'Image or Image(X). >> >> In which way would you change T'Value for symmetry? > > "123"'Value or Value("123"), of course Looks like dispatching, overload resolution, and more efforts in generics... No? procedure F is type F1 is digits 4; type F2 is digits 7; procedure Take_Float (X : F1) is begin Put_Line ("I'm an F1"); end Take_Float; procedure Take_Float (X : F2) is begin Put_Line ("I'm an F2"); end Take_Float; S : constant String := "12.3"; begin Take_Float (X => Value(S)); -- which one? end F; ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 15:36 ` Georg Bauhaus @ 2011-08-31 15:53 ` Dmitry A. Kazakov 2011-08-31 16:23 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 15:53 UTC (permalink / raw) On Wed, 31 Aug 2011 17:36:11 +0200, Georg Bauhaus wrote: > On 31.08.11 16:44, Dmitry A. Kazakov wrote: >> On Wed, 31 Aug 2011 08:16:35 +0200, Georg Bauhaus wrote: >>> >>> In which way would you change T'Value for symmetry? >> >> "123"'Value or Value("123"), of course > > Looks like dispatching, overload resolution, and more > efforts in generics... No? Ada is not C++. > procedure F is > > type F1 is digits 4; > type F2 is digits 7; > > procedure Take_Float (X : F1) is > begin > Put_Line ("I'm an F1"); > end Take_Float; > > procedure Take_Float (X : F2) is > begin > Put_Line ("I'm an F2"); > end Take_Float; > > S : constant String := "12.3"; > begin > Take_Float (X => Value(S)); -- which one? Take_Float (X => 1.2); -- which one? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 15:53 ` Dmitry A. Kazakov @ 2011-08-31 16:23 ` Georg Bauhaus 2011-08-31 16:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 16:23 UTC (permalink / raw) On 31.08.11 17:53, Dmitry A. Kazakov wrote: >> procedure F is >> >> type F1 is digits 4; >> type F2 is digits 7; >> >> procedure Take_Float (X : F1) is >> begin >> Put_Line ("I'm an F1"); >> end Take_Float; >> >> procedure Take_Float (X : F2) is >> begin >> Put_Line ("I'm an F2"); >> end Take_Float; >> >> S : constant String := "12.3"; >> begin >> Take_Float (X => Value(S)); -- which one? > > Take_Float (X => 1.2); -- which one? Take_Float (X => F1'(1.2)); -- obviously :-) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:23 ` Georg Bauhaus @ 2011-08-31 16:27 ` Dmitry A. Kazakov 2011-08-31 16:30 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 16:27 UTC (permalink / raw) On Wed, 31 Aug 2011 18:23:44 +0200, Georg Bauhaus wrote: > On 31.08.11 17:53, Dmitry A. Kazakov wrote: > >>> procedure F is >>> >>> type F1 is digits 4; >>> type F2 is digits 7; >>> >>> procedure Take_Float (X : F1) is >>> begin >>> Put_Line ("I'm an F1"); >>> end Take_Float; >>> >>> procedure Take_Float (X : F2) is >>> begin >>> Put_Line ("I'm an F2"); >>> end Take_Float; >>> >>> S : constant String := "12.3"; >>> begin >>> Take_Float (X => Value(S)); -- which one? >> >> Take_Float (X => 1.2); -- which one? > > Take_Float (X => F1'(1.2)); -- obviously :-) Take_Float (X => F1'(Value(S))); -- Ditto! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:27 ` Dmitry A. Kazakov @ 2011-08-31 16:30 ` Georg Bauhaus 2011-08-31 16:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 16:30 UTC (permalink / raw) On 31.08.11 18:27, Dmitry A. Kazakov wrote: > On Wed, 31 Aug 2011 18:23:44 +0200, Georg Bauhaus wrote: > >> On 31.08.11 17:53, Dmitry A. Kazakov wrote: >> >>>> procedure F is >>>> >>>> type F1 is digits 4; >>>> type F2 is digits 7; >>>> >>>> procedure Take_Float (X : F1) is >>>> begin >>>> Put_Line ("I'm an F1"); >>>> end Take_Float; >>>> >>>> procedure Take_Float (X : F2) is >>>> begin >>>> Put_Line ("I'm an F2"); >>>> end Take_Float; >>>> >>>> S : constant String := "12.3"; >>>> begin >>>> Take_Float (X => Value(S)); -- which one? >>> >>> Take_Float (X => 1.2); -- which one? >> >> Take_Float (X => F1'(1.2)); -- obviously :-) > > Take_Float (X => F1'(Value(S))); -- Ditto! Take_Float (X => F1'Value(S)); -- to be less "silly and redundant"? :-) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:30 ` Georg Bauhaus @ 2011-08-31 16:50 ` Dmitry A. Kazakov 2011-08-31 20:41 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 16:50 UTC (permalink / raw) On Wed, 31 Aug 2011 18:30:17 +0200, Georg Bauhaus wrote: > On 31.08.11 18:27, Dmitry A. Kazakov wrote: >> On Wed, 31 Aug 2011 18:23:44 +0200, Georg Bauhaus wrote: >> >>> On 31.08.11 17:53, Dmitry A. Kazakov wrote: >>> >>>>> procedure F is >>>>> >>>>> type F1 is digits 4; >>>>> type F2 is digits 7; >>>>> >>>>> procedure Take_Float (X : F1) is >>>>> begin >>>>> Put_Line ("I'm an F1"); >>>>> end Take_Float; >>>>> >>>>> procedure Take_Float (X : F2) is >>>>> begin >>>>> Put_Line ("I'm an F2"); >>>>> end Take_Float; >>>>> >>>>> S : constant String := "12.3"; >>>>> begin >>>>> Take_Float (X => Value(S)); -- which one? >>>> >>>> Take_Float (X => 1.2); -- which one? >>> >>> Take_Float (X => F1'(1.2)); -- obviously :-) >> >> Take_Float (X => F1'(Value(S))); -- Ditto! > > Take_Float (X => F1'Value(S)); -- to be less "silly and redundant"? :-) Exactly! (I hope you aren't arguing that F1'(1.2) must be used instead of 1.2) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:50 ` Dmitry A. Kazakov @ 2011-08-31 20:41 ` Georg Bauhaus 2011-08-31 21:17 ` Robert A Duff 2011-09-01 7:46 ` Dmitry A. Kazakov 0 siblings, 2 replies; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 20:41 UTC (permalink / raw) On 31.08.11 18:50, Dmitry A. Kazakov wrote: > On Wed, 31 Aug 2011 18:30:17 +0200, Georg Bauhaus wrote: > >> On 31.08.11 18:27, Dmitry A. Kazakov wrote: >>> On Wed, 31 Aug 2011 18:23:44 +0200, Georg Bauhaus wrote: >>> >>>> On 31.08.11 17:53, Dmitry A. Kazakov wrote: >>>> >>>>>> procedure F is >>>>>> >>>>>> type F1 is digits 4; >>>>>> type F2 is digits 7; >>>>>> >>>>>> procedure Take_Float (X : F1) is >>>>>> begin >>>>>> Put_Line ("I'm an F1"); >>>>>> end Take_Float; >>>>>> >>>>>> procedure Take_Float (X : F2) is >>>>>> begin >>>>>> Put_Line ("I'm an F2"); >>>>>> end Take_Float; >>>>>> >>>>>> S : constant String := "12.3"; >>>>>> begin >>>>>> Take_Float (X => Value(S)); -- which one? >>>>> >>>>> Take_Float (X => 1.2); -- which one? >>>> >>>> Take_Float (X => F1'(1.2)); -- obviously :-) >>> >>> Take_Float (X => F1'(Value(S))); -- Ditto! >> >> Take_Float (X => F1'Value(S)); -- to be less "silly and redundant"? :-) > > Exactly! > > (I hope you aren't arguing that F1'(1.2) must be used instead of 1.2) Not in the general case (F1'() being required in the case at hand), Still SPARK, and in some more cases Ada, do require that we write T'() anyway: to resolve another ambiguity (of ()). Anyone to suggest finally using [] for aggregates? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 20:41 ` Georg Bauhaus @ 2011-08-31 21:17 ` Robert A Duff 2011-09-01 7:36 ` Dmitry A. Kazakov 2011-09-01 7:46 ` Dmitry A. Kazakov 1 sibling, 1 reply; 64+ messages in thread From: Robert A Duff @ 2011-08-31 21:17 UTC (permalink / raw) Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes: > Anyone to suggest finally using [] for aggregates? I have suggested that many times. Then we could have zero- and one-element positional aggregates. - Bob ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 21:17 ` Robert A Duff @ 2011-09-01 7:36 ` Dmitry A. Kazakov 0 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-01 7:36 UTC (permalink / raw) On Wed, 31 Aug 2011 17:17:13 -0400, Robert A Duff wrote: > Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes: > >> Anyone to suggest finally using [] for aggregates? > > I have suggested that many times. Then we could have zero- and > one-element positional aggregates. There is no ambiguity in one-element aggregates. But [] brackets could be useful as an operation, which user could define. Similarly {}, (), ||. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 20:41 ` Georg Bauhaus 2011-08-31 21:17 ` Robert A Duff @ 2011-09-01 7:46 ` Dmitry A. Kazakov 2011-09-01 9:50 ` Overloading parentheses and type expectations (was: The simple Image issue) Georg Bauhaus 1 sibling, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-01 7:46 UTC (permalink / raw) On Wed, 31 Aug 2011 22:41:01 +0200, Georg Bauhaus wrote: > Still SPARK, and in some more cases Ada, do require that we write > T'() anyway: to resolve another ambiguity (of ()). Fix SPARK! There is no usable languages without overloading. Since you mentioned () [meaning aggregates], think about them used for ordering: (x) returns what? For each type and subtype of x there is some "()". They all are overloaded. Do you wish to annotate each of them? I := Integer'(1 + 2) * 4 ? But what about +,-,*,/? Since the dictionary of any language is far less than the number of entities an average program in that language describes, you simply cannot avoid some kinds overloading. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Overloading parentheses and type expectations (was: The simple Image issue) 2011-09-01 7:46 ` Dmitry A. Kazakov @ 2011-09-01 9:50 ` Georg Bauhaus 2011-09-02 7:54 ` Overloading parentheses and type expectations Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-09-01 9:50 UTC (permalink / raw) On 01.09.11 09:46, Dmitry A. Kazakov wrote: > On Wed, 31 Aug 2011 22:41:01 +0200, Georg Bauhaus wrote: > >> Still SPARK, and in some more cases Ada, do require that we write >> T'() anyway: to resolve another ambiguity (of ()). > > Fix SPARK! Not. At least if this makes me an inference machine for "()"; a "disambiguator"; or a de-obfuscator of clever abbreviations, omitted names, and long lists of positional parameters. What is the use of clever detection? To show that in f(1), given function f, the 1 can only be a an array of length 1? This, to me, is obfuscation. > There is no usable languages without overloading. Since you mentioned () > [meaning aggregates], think about them used for ordering: > > (x) > > returns what? For each type and subtype of x there is some "()". They all > are overloaded. Do you wish to annotate each of them? There is evidence that overloading the meaning of () is not working with normal people, e.g. McIver & Conway (1996). They arent't aguing about advanced programmers, though. The Turing language has made () a kind of universal "pick from" operator, arrays, dereferencing, taking part-of, ..., besides the usual uses. Readers will need to disambiguate uses of "()" if they want to know what some expression actually does. Some programmers want to know what an expression does. Other programmers must know what an expression does. M & C found that Turing made it difficult to learn the differences between things all written using "()". Why would a designer want entirely different things in a language and then use the same notation for all of them? Given the evidence, I think the disadvantages outweigh the advantages. > I := Integer'(1 + 2) * 4 ? Qualification, association, and infix operators. First, infix expressions are a (dis)service offered to programmers whose wish is less to program a computer, but rather to write executable formal expressions (such as non-CS formulas) in blissful ignorance of the computer. (Even when they like HP calculators...) Infix doesn't work well unless the subject is more or less mathematical and when work can ignore TIME and SPACE. I cannot say it better than, http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful Then, infix is complex to understand when the model is otherwise that of simple object oriented programming (ignoring inheritance). In 3 + 5 (or x + y), which object does "+" manipulate? Or will the execution update the "+" object? Consider a := 1; a.add(2); if a /= 3 then raise Program_Error; end if; This would put me in a different mode of thinking, and of understanding. There are no operational effects (or surprises!) of association and precedence. Third, an occurrence of qualifying T'(...) frequently creates an object. When the object appears alone, as in a typical initialization expression, repeating the type's name may seem silly and redundant. Just for context, some less specific circumstances. declare X : T0'class := T3'( ... ); begin is different from declare X : T3 := ( ... ); begin and different from Integer'(1 + 2) * 4 "Qualifying" in a different way, though much like Integer'(1 + 2) is not without uses: for P in Pins range 1 .. 3 loop rather than for P in 1 .. 3 loop carries more information, and will add information that is sometimes necessary for the Ada compiler to know the literals and their types. I don't find them necessarily silly and redundant. Strict, yes. > Since the dictionary of any language is far less than the number of > entities an average program in that language describes, you simply cannot > avoid some kinds overloading. Sometimes overriding works better than overloading. At the level of overloading ASCII punctuation, I think the less, the better. Use symbols only for things heavily loaded with meaning. The art is in finding the right weight. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Overloading parentheses and type expectations 2011-09-01 9:50 ` Overloading parentheses and type expectations (was: The simple Image issue) Georg Bauhaus @ 2011-09-02 7:54 ` Dmitry A. Kazakov 2011-09-02 10:37 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-02 7:54 UTC (permalink / raw) On Thu, 01 Sep 2011 11:50:59 +0200, Georg Bauhaus wrote: > On 01.09.11 09:46, Dmitry A. Kazakov wrote: >> On Wed, 31 Aug 2011 22:41:01 +0200, Georg Bauhaus wrote: >> >>> Still SPARK, and in some more cases Ada, do require that we write >>> T'() anyway: to resolve another ambiguity (of ()). >> >> Fix SPARK! > > Not. At least if this makes me an inference machine for "()"; > a "disambiguator"; or a de-obfuscator of clever abbreviations, > omitted names, and long lists of positional parameters. > > What is the use of clever detection? 1. Common sense. 2. Limitations put on human brain. We can memorize only a few concepts and whatever we see or do has to be broken into these basic concepts, e.g. "additive". > To show that in > > f(1), > > given function f, the 1 can only be a an array of length 1? It cannot, because f is not a prefix operation. Anyway, ANY written language needs understanding (translation into the domain). Are you arguing for a hieroglyphic language where each possible program has a corresponding alphabet symbol? >> There is no usable languages without overloading. Since you mentioned () >> [meaning aggregates], think about them used for ordering: >> >> (x) >> >> returns what? For each type and subtype of x there is some "()". They all >> are overloaded. Do you wish to annotate each of them? > > > There is evidence that overloading the meaning of () is not > working with normal people, e.g. McIver & Conway (1996). Rubbish, mathematical notation is taught in school. It is easy to show that all known alternatives (e.g. Polish expressions) are incomprehensive for normal people. > Why would a designer want entirely different things in a language > and then use the same notation for all of them? See above. This is the way human brain works. And the things are not entirely different, they are instances of some class. The language captures this by using "+" everywhere "addition" is meant. > First, infix expressions are a (dis)service offered to programmers > whose wish is less to program a computer, I'd like to see a hard proof that, for instance, Forth is more productive, safer, easier to understand, etc than Ada. > I cannot say it better than, > http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful The text is about levels of precedence. They were probably unaware of the simple fact, that ambiguity should not be resolved using precedence as in C. For proper language design see Ada, where ambiguity stay unresolved: X and Y or Z -- Ambiguous => erroneous > In 3 + 5 (or x + y), which object does "+" manipulate? Three objects: 1. The left argument 2. The right argument 3. The result All this has nothing to do with the notation. Whether "+" is used as an infix operation or as a function call, its semantics remains exactly the same. > Third, an occurrence of qualifying T'(...) frequently creates an object. I doubt it. Anyway, semantically there should be no difference. > "Qualifying" in a different way, though much like Integer'(1 + 2) is not > without uses: > > for P in Pins range 1 .. 3 loop > > rather than > > for P in 1 .. 3 loop > > carries more information, and will add information that is sometimes > necessary for the Ada compiler to know the literals and their types. > I don't find them necessarily silly and redundant. Information unnecessary to understanding the program is noise. When also required by the compiler, it constitutes a language deficiency. (There could be some exceptions from this rule) >> Since the dictionary of any language is far less than the number of >> entities an average program in that language describes, you simply cannot >> avoid some kinds overloading. > > Sometimes overriding works better than overloading. Both are cases of polymorphism. It is OK to inherit "+" from some common base. Unfortunately Ada cannot this due to lack of MD, MI and interface inheritance. But that would change nothing at the syntax level: 1+2 would remain 1+2 (as it should be). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Overloading parentheses and type expectations 2011-09-02 7:54 ` Overloading parentheses and type expectations Dmitry A. Kazakov @ 2011-09-02 10:37 ` Georg Bauhaus 2011-09-02 12:40 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-09-02 10:37 UTC (permalink / raw) On 02.09.11 09:54, Dmitry A. Kazakov wrote: > Rubbish, mathematical notation is taught in school. It is easy to show that > all known alternatives (e.g. Polish expressions) are incomprehensive for > normal people. Still, I hesitate to call empirical findings "rubbish". Mathematical notation may, and does, use a circled ⊕, not + when the writer wants to emphasize that she isn't referring to some "known" +. Also, dot minus, ∸, is sometimes used for subtraction never going below 0. The use of ∫ is common for indicating an integral. TTBOMK, the symbol isn't used to denote anything but integrals. Unlike the way () has many uses in Ada. And ∫ is not used in Ada (or similar languages), but + is. Why? Is there anything about + that makes its meaning more special than that of ∫? More worthy of being included in the language? Is + better adjusted to how our brain works than ∫ and that therefore is a privileged symbol? Or is it habit + keyboard? I guess it is. No need to refer to cognitive psychology. When computers had less characters for syntax, and programmers typed <<< x : x in S .ST. P(x) >>> or similar instead of {x : x in S | P(x)}, they quickly gave up overloaded < etc when {} and | became available. Why? Because (a) they are easier to type, (b) they were expected in the first place. There is sanity in finding a break even point between time spent deciphering ASCII symbolism at one extreme and symbolitis at the other. >> Why would a designer want entirely different things in a language >> and then use the same notation for all of them? > > See above. This is the way human brain works. And the things are not > entirely different, they are instances of some class. The language captures > this by using "+" everywhere "addition" is meant. In order to capture meaning of classes, one first has to learn and become aware and become familiar with what a class is before even touching and understanding of class. Those not familiar with CS abstractions, maybe even those who are familiar with CS abstractions, have not found it obvious that a pointer dereference written p() is the same thing as an array indexing operation written a(), or as a function call written f(). Cute as it may seem, common as it may seem, conceptually sound as it may seem, expressing differences using .all, [], or () seems to help programmers understand programs. And then you would have to go the other way, too, from the common aspect and the identical syntax for different thingswhen debugging and trying to determine what kind of () is causing trouble. Proof: The lengthy and recurring discussion of a[i] being the same as *(a + i) in C does not take place when explaining Ada arrays; but Ada programmers will need to do some overload resolution work when seeing x(y). >> First, infix expressions are a (dis)service offered to programmers >> whose wish is less to program a computer, > > I'd like to see a hard proof that, for instance, Forth is more productive, > safer, easier to understand, etc than Ada. (Von Neumann called early Fortran notation a waste...) OK, I'm assuming people insist that infix is really a must; Although ... only with elementary math operators... Oh, and with logical operators. One ingredient of productive programming is the principle of least surprise. Overflow is one of the surprises. : 1 Max_Int + N - ; (- (+ 1 Max_Int) N) 1 + Max_Int - N; (1 + Max_Int) - N; Presuming familiarity with either language, why would the human brain be better at detecting the error on line 3 and not on lines 1,2,4? Even though, if I understand correctly, the brain isn't aided by distinct syntax when breaking things down? Note that the parens above have only one meaning. > Whether "+" is used as an > infix operation or as a function call, its semantics remains exactly the > same. The phrase "its semantics" is stipulating a specific interpretation of binary "+"; Smalltalk is assigning different meaning to "+", at least using very different reasoning (to the untrained). But you do write x + y ... Meaning is also unclear when languages have rules (or not) explaining the order of evaluation of arguments; or the effects of aliasing in the presence of optimization. I'm saying this not because Ada didn't care, it does, but because nothing of all this is visible to the reader studying the expression, infix or not. The human brain needs to learn, and then to rummage through a mountain of, information about the expression and its meaning in order to see, for example, from where this strange and irregularly occurring difference in executing x + y should stem, for seemingly the same x and y, by the looks of it. (Timing dependent shared variable update through y, say.) > Information unnecessary to understanding the program is noise. When also > required by the compiler, it constitutes a language deficiency. (There > could be some exceptions from this rule) Understanding is on a scale. This is why we say "easily understood". This is why I say that I do not want to be forced into being an inference machine without need. Just to understand something that is totally obvious and consistent with some little additions I'm fine with, yes, even redundancies. And redundancy is subjective, of course. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Overloading parentheses and type expectations 2011-09-02 10:37 ` Georg Bauhaus @ 2011-09-02 12:40 ` Dmitry A. Kazakov 2011-09-02 16:08 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-02 12:40 UTC (permalink / raw) On Fri, 02 Sep 2011 12:37:17 +0200, Georg Bauhaus wrote: > On 02.09.11 09:54, Dmitry A. Kazakov wrote: > >> Rubbish, mathematical notation is taught in school. It is easy to show that >> all known alternatives (e.g. Polish expressions) are incomprehensive for >> normal people. > > Still, I hesitate to call empirical findings "rubbish". empirical, adj ... 2. based on practical experience rather than scientific proof 3. (of a proposition) subject, at least theoretically, to verification 4. (Medicine) of or relating to medical quackery Would "quackery" be OK? (:-)) > Mathematical notation may, and does, use a circled ⊕, > not + when the writer wants to emphasize that she isn't > referring to some "known" +. + is used for all kinds of additive elements, numbers, vectors, matrices etc. > The use of ∫ is common for indicating an integral. Integral is not an addition. Addition is used by (Lebesque) integration, but defined on a set measure. It has the standard notation +, e.g. µ(A U B) = µ(A) + µ(B) if A and B are disjoint, etc > Is there anything about + that makes its meaning more special > than that of ∫? Yes. Integral is a value according to some measure. + is an operation of a group. (I hope you won't argue that * is addition because it could be defined in terms of +) >>> Why would a designer want entirely different things in a language >>> and then use the same notation for all of them? >> >> See above. This is the way human brain works. And the things are not >> entirely different, they are instances of some class. The language captures >> this by using "+" everywhere "addition" is meant. > > In order to capture meaning of classes, one first has to learn and > become aware and become familiar with what a class is before even > touching and understanding of class. Those not familiar with CS > abstractions, maybe even those who are familiar with CS abstractions, > have not found it obvious that a pointer dereference written p() > is the same thing as an array indexing operation written a(), > or as a function call written f(). Sorry, people can be unaware of anything. Why, for somebody unaware of +, Integer'(Add (Integer'(1), Integer'(2)) would become more understandable? Is he aware of Integer? Of 1, 2. What does the apostrophe mean? Does it stand for gender? Is '(Add (Integer' a string. What is string? > Proof: The lengthy and recurring discussion of a[i] being > the same as *(a + i) in C does not take place when explaining > Ada arrays; but Ada programmers will need to do some > overload resolution work when seeing x(y). Nope. Mathematically there is no difference between an array and a valued pure subprogram. Both are run-time implementations of a mapping. Why there should be different notation for them? > One ingredient of productive programming is the principle > of least surprise. Overflow is one of the surprises. > >: 1 Max_Int + N - ; > > (- (+ 1 Max_Int) N) > > 1 + Max_Int - N; > > (1 + Max_Int) - N; > > Presuming familiarity with either language, why would the human > brain be better at detecting the error on line 3 and not on > lines 1,2,4? Even though, if I understand correctly, the brain > isn't aided by distinct syntax when breaking things down? 1. Overflow is not an error it is a valid, mandated behavior. 2. If the contract excludes overflow then, the only correct line is #3, since the compiler is allowed to reorder the expression to produce the mathematically correct result. > Note that the parens above have only one meaning. Wrong. There are two meanings of brackets above: 1. "()" : N -> N , e.g. (1)=1 2. "()" : <exceptional-state> -> <exceptional-state> , e.g. Constraint_Error is propagated out of brackets. >> Whether "+" is used as an >> infix operation or as a function call, its semantics remains exactly the >> same. > > The phrase "its semantics" is stipulating a specific interpretation > of binary "+"; Smalltalk is assigning different meaning to "+", > at least using very different reasoning (to the untrained). I care little of Smalltalk (sorry, for unintended pun). > But you do write x + y ... > Meaning is also unclear when languages have rules (or not) > explaining the order of evaluation of arguments; or the effects > of aliasing in the presence of optimization. That does not change the semantics of +. The semantics of an expression (or a program) depends on the semantics of its parts, but is not equivalent to them. The composition rules of the language tell you how these parts are supposed to interplay. > The human brain needs to learn, and then to rummage through a mountain > of, information about the expression and its meaning in order to see, > for example, from where this strange and irregularly occurring difference > in executing x + y should stem, for seemingly the same x and y, by the > looks of it. (Timing dependent shared variable update through y, say.) And a consistent use of Whatever.Package.Name.Add instead of + is supposed to ease the process of learning? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Overloading parentheses and type expectations 2011-09-02 12:40 ` Dmitry A. Kazakov @ 2011-09-02 16:08 ` Georg Bauhaus 2011-09-02 17:29 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-09-02 16:08 UTC (permalink / raw) On 02.09.11 14:40, Dmitry A. Kazakov wrote: > empirical, adj > ... > 2. based on practical experience rather than scientific proof > 3. (of a proposition) subject, at least theoretically, to verification > 4. (Medicine) of or relating to medical quackery The non-scientific meanings are not applicable to how this study of understanding programming languages was conducted. > Integral is not an addition. Other operations aren't addition either, yet some are considered more worthy of inclusion as infix symbols than others. I just think that language design should reflect computers' + more than + from school. How? Specialists in using + let us know that most programmers have no idea of what they are doing, for example, when adding floats. (I don't say I have. Dewar, author of a number of chapters on FPT units in microprocessors, has hinted that he will consult specialists, so I don't feed all too bad.) Still we all write x + y, and many don't care what this actually means. The point is: the language does not draw attention to + as a source of errors induced by school think. It does not encourage learning about computer addition by making the default syntax for + so conventional. > Addition is used by (Lebesque) integration, > but defined on a set measure. It has the standard notation +, e.g. > > µ(A U B) = µ(A) + µ(B) if A and B are disjoint, etc µ is equally abhorred, as is ∪. Maybe ∪ should not be used in languages other than SETL because ∪ implies properties of data structures that typical implementations of a Set will not have? >> Is there anything about + that makes its meaning more special >> than that of ∫? > > Yes. Integral is a value according to some measure. + is an operation of a > group. (I hope you won't argue that * is addition because it could be > defined in terms of +) This is a mathematical perspective on mathematical properties only, not simply on program text. In a computer program, you write + (1, 2) ∫ (f'access, a, b) How is ∫ special? I'm *not* suggesting ∫ should be specially present in a general purpose programming language. But, by the same token, I think that + should trigger the same restraint as do ∫ or ∪. At the very least, an operator such as + should not be predefined to the maximum extent possible. The operator should convey that it will not perform high school addition but computer addition. We would be getting better programs, because programmers are better informed. > Sorry, people can be unaware of anything. We typically assume that we are aware of the meaning of expressions. But we frequently aren't, and more so when the language obfuscates actual differences by painting them all in the same mathematical color (syntax), such as in the pointer(), array(), and function() examples. Makes them all look the same, even though they behave differently. There wouldn't be different mechanism in a language otherwise, would there? > Nope. Mathematically there is no difference between an array and a valued > pure subprogram. Both are run-time implementations of a mapping. Why there > should be different notation for them? The study by McIver & Conway explains a number of reasons, all having to do with programmers. > 1. Overflow is not an error it is a valid, mandated behavior. I still don't want most programs to overflow. Mistakes are not mandated behavior, unless you share Microsoft's office sales strategy. > Wrong. There are two meanings of brackets above: > > 1. "()" : N -> N , e.g. (1)=1 > > 2. "()" : <exceptional-state> -> <exceptional-state> , e.g. > Constraint_Error is propagated out of brackets. Which, I guess, can be reduced to "()" : N_|_ -> N_|_ > I care little of Smalltalk (sorry, for unintended pun). To me, it matters what programmers think about +, and about how + works, and about what happens to the operands. Thus, what they think about what happens in x + y - z, and how a language's syntax helps with understanding what actually happens. > That does not change the semantics of +. The symbol + has no semantics of its own, like you explain later. >> The human brain needs to learn, and then to rummage through a mountain >> of, information about the expression and its meaning in order to see, >> for example, from where this strange and irregularly occurring difference >> in executing x + y should stem, for seemingly the same x and y, by the >> looks of it. (Timing dependent shared variable update through y, say.) > > And a consistent use of Whatever.Package.Name.Add instead of + is supposed > to ease the process of learning? Not + alone, but a suitably defined language allowing programmers to express their expectations, and be given clear and simple indications of its effects. If a language mandates the use of grouping, (x + y) not x + y, then this rule draws attention to the effects of association in a computer. A simple example, also related to "the semantics of symbols": a = a + 1 The hypothetical student sees this statement when she is first exposed to programming in her life (BASIC). She then reads all the gibberish about storage locations, accumulators and whatnots, but stills has no idea just how a number can be equal to its successor! `=' is very unmathematical in most programming languages, yet programmers fervently defend its choice. The + case is lighter I think, but otherwise not much different. What can aid understanding? The Semitic languages, when written and read by specialists, leave out the vowels. Similarly, trained readers can understand a text written in shorthand. Likewise, cryptographers will have little difficulty assigning meaning to hexadecimal gobbledegook. If the three groups of specialists write diacritics for vowels, write in "normal hand", or don't encrypt their messages, respectively, then this is a first step towards understanding. Revert the removal of subjectively felt redundancy. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Overloading parentheses and type expectations 2011-09-02 16:08 ` Georg Bauhaus @ 2011-09-02 17:29 ` Dmitry A. Kazakov 0 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-02 17:29 UTC (permalink / raw) On Fri, 02 Sep 2011 18:08:49 +0200, Georg Bauhaus wrote: > On 02.09.11 14:40, Dmitry A. Kazakov wrote: > >> empirical, adj >> ... >> 2. based on practical experience rather than scientific proof >> 3. (of a proposition) subject, at least theoretically, to verification >> 4. (Medicine) of or relating to medical quackery > > The non-scientific meanings are not applicable to how this study > of understanding programming languages was conducted. Obviously this study has little to do with science. I have no idea how such stuff passes peer reviews... >> Integral is not an addition. > > Other operations aren't addition either, yet some are considered > more worthy of inclusion as infix symbols than others. I just think > that language design should reflect computers' + more than + from > school. No, it should not. > The point is: the language does not draw attention to + > as a source of errors induced by school think. No, the semantics of + is defined pretty clear and it is consistent with the school mathematics. + does not mean the group operation of Z. Computers do not handle Z. + means "addition". >> Addition is used by (Lebesque) integration, >> but defined on a set measure. It has the standard notation +, e.g. >> >> µ(A U B) = µ(A) + µ(B) if A and B are disjoint, etc > > µ is equally abhorred, as is ∪. Maybe ∪ should not be used > in languages other than SETL because ∪ implies properties > of data structures that typical implementations of a Set will > not have? How so? Bot µ and U represent absolutely no problem, so long sets are finite, which is 99.9% of all cases modeled using computer programs. >>> Is there anything about + that makes its meaning more special >>> than that of ∫? >> >> Yes. Integral is a value according to some measure. + is an operation of a >> group. (I hope you won't argue that * is addition because it could be >> defined in terms of +) > > This is a mathematical perspective on mathematical properties only, > not simply on program text. In a computer program, you write > > + (1, 2) > ∫ (f'access, a, b) > > How is ∫ special? Integration is special, because incomputable. The approximations of, done by computers, are too implementation-dependent to be abstracted in the way used in mathematics. On the contrary, the implementations of model numbers are much more simpler and closer to their mathematical counterparts. No less important is that model numbers indeed form the structures (rings etc) of same nature (properties) as the corresponding mathematical structures. > At the very least, an operator such as + should not be predefined to > the maximum extent possible. The operator should convey that it > will not perform high school addition but computer addition. No. E.g. + of mod 2**16 means exactly same, the mathematical + does. >> Nope. Mathematically there is no difference between an array and a valued >> pure subprogram. Both are run-time implementations of a mapping. Why there >> should be different notation for them? > > The study by McIver & Conway explains a number of reasons, > all having to do with programmers. I don't buy such "studies" on methodological grounds. Whatever explanations they give, that is an urban myth. You, me and anybody else here is capable to produce tons of such stuff. Meanwhile the hard facts are impossible to gather in any statistically relevant form, because such experiments would cost billions of bucks and require very sophisticated methods to develop. For the rest see Ernest Rutherford about science and stamp collecting. We could only be happy that guys "studying" programming languages have not a ounce of influence on the governments, the "climatologists" have. Lysenko is dead, but his cause lives. >> 1. Overflow is not an error it is a valid, mandated behavior. > > I still don't want most programs to overflow. Then they should not let overflow happen. >>> The human brain needs to learn, and then to rummage through a mountain >>> of, information about the expression and its meaning in order to see, >>> for example, from where this strange and irregularly occurring difference >>> in executing x + y should stem, for seemingly the same x and y, by the >>> looks of it. (Timing dependent shared variable update through y, say.) >> >> And a consistent use of Whatever.Package.Name.Add instead of + is supposed >> to ease the process of learning? > > Not + alone, but a suitably defined language allowing programmers > to express their expectations, and be given clear and simple indications > of its effects. I am not against manifested contracts, as you probably know. But the idea that syntax should convey contract is all wrong. It won't work, it never worked. The contracts belong to the types. > What can aid understanding? The language should convey the idea at different levels of abstraction. It is like a good movie or a good book. Anybody can find there something at his level of depth or shallowness. Understanding works by recognition of common concepts and patterns with an ability to go deeper, gradually down to the bottom, but only when felt needed. This makes a good language. C is bad because it does what you wanted, it requires full, persistent, concentrated attention to each tinny piece of the code written or read. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 6:16 ` The simple Image issue (was: Address and bit mask) Georg Bauhaus 2011-08-31 14:44 ` The simple Image issue Dmitry A. Kazakov @ 2011-08-31 15:53 ` Hyman Rosen 2011-08-31 16:07 ` Dmitry A. Kazakov ` (2 more replies) 2011-08-31 16:08 ` The simple Image issue (was: Address and bit mask) Adam Beneschan 2 siblings, 3 replies; 64+ messages in thread From: Hyman Rosen @ 2011-08-31 15:53 UTC (permalink / raw) On 8/31/2011 2:16 AM, Georg Bauhaus wrote: > In which way would you change T'Value for symmetry? You wouldn't, because the symmetry is false. When you already have an object, being forced to name its type is silly and redundant. When you have a string and want it converted to an object, of course you need to say what type it's becoming. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 15:53 ` The simple Image issue Hyman Rosen @ 2011-08-31 16:07 ` Dmitry A. Kazakov 2011-08-31 16:08 ` Simon Wright 2011-08-31 16:25 ` Georg Bauhaus 2 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 16:07 UTC (permalink / raw) On Wed, 31 Aug 2011 11:53:17 -0400, Hyman Rosen wrote: > On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >> In which way would you change T'Value for symmetry? > > You wouldn't, because the symmetry is false. When you > already have an object, being forced to name its type > is silly and redundant. When you have a string and want > it converted to an object, of course you need to say > what type it's becoming. However type conversion is another beast. If I designed the language I would support ad-hoc subtypes (ones established dynamically in some scope without implementation inheritance). E.g. in some context one could make Integer a subtype of String and just write: I : Integer; ... Put_Line ("I=" & I); Static type relationships, even with MI and MD support, are not flexible enough to handle cases like I/O, containers etc in a generic way. You need an ability to create a virtual parent for unrelated types later on to be able to have a class of these types (on order to define operations handling instances from this class). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 15:53 ` The simple Image issue Hyman Rosen 2011-08-31 16:07 ` Dmitry A. Kazakov @ 2011-08-31 16:08 ` Simon Wright 2011-08-31 16:26 ` Dmitry A. Kazakov 2011-08-31 16:25 ` Georg Bauhaus 2 siblings, 1 reply; 64+ messages in thread From: Simon Wright @ 2011-08-31 16:08 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >> In which way would you change T'Value for symmetry? > > You wouldn't, because the symmetry is false. When you > already have an object, being forced to name its type > is silly and redundant. When you have a string and want > it converted to an object, of course you need to say > what type it's becoming. I would have thought overload resolution would solve a lot of problems? X : Integer := "123"'Value; Y : Float := "1.0e-9"'Value; (not that I approve of the suggestion, quite happy with the current setup for 'Value. On the other hand, I'm a frequent user of GNAT's 'Img - not of course in code that's intended to be portable!) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:08 ` Simon Wright @ 2011-08-31 16:26 ` Dmitry A. Kazakov 0 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-08-31 16:26 UTC (permalink / raw) On Wed, 31 Aug 2011 17:08:51 +0100, Simon Wright wrote: > Hyman Rosen <hyrosen@mail.com> writes: > >> On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >>> In which way would you change T'Value for symmetry? >> >> You wouldn't, because the symmetry is false. When you >> already have an object, being forced to name its type >> is silly and redundant. When you have a string and want >> it converted to an object, of course you need to say >> what type it's becoming. > > I would have thought overload resolution would solve a lot of problems? > > X : Integer := "123"'Value; > Y : Float := "1.0e-9"'Value; Yes, in my string editing library, it is just overloaded functions: X : Integer := Value ("123"); Y : Float := Value ("1.0e-9"); No problem to resolve. The real problem is that the thing is generic. A built-in function does not need boring instantiations. P.S. There exist subtle issues with subtypes, e.g. X : Positive := Value ("-123"); The question is whether the constraint has to be known within the operation or not. In most cases the operation can operate on the parent checking the constraint upon setting the target: Positive's Value = Positive o Integer's Value But for things like enumeration extensions (i.e. subtypes weakening constraints rather than strengthening them), this would become a problem. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 15:53 ` The simple Image issue Hyman Rosen 2011-08-31 16:07 ` Dmitry A. Kazakov 2011-08-31 16:08 ` Simon Wright @ 2011-08-31 16:25 ` Georg Bauhaus 2011-08-31 16:30 ` Hyman Rosen 2 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 16:25 UTC (permalink / raw) On 31.08.11 17:53, Hyman Rosen wrote: > On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >> In which way would you change T'Value for symmetry? > > You wouldn't, because the symmetry is false. When you > already have an object, being forced to name its type > is silly and redundant. True when there is an object; but what about (some expression)'Value ? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:25 ` Georg Bauhaus @ 2011-08-31 16:30 ` Hyman Rosen 2011-08-31 16:34 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Hyman Rosen @ 2011-08-31 16:30 UTC (permalink / raw) On 8/31/2011 12:25 PM, Georg Bauhaus wrote: > On 31.08.11 17:53, Hyman Rosen wrote: >> On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >>> In which way would you change T'Value for symmetry? >> >> You wouldn't, because the symmetry is false. When you >> already have an object, being forced to name its type >> is silly and redundant. > > True when there is an object; but what about > > (some expression)'Value ? Use T(expression)'Value when you must. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:30 ` Hyman Rosen @ 2011-08-31 16:34 ` Georg Bauhaus 2011-08-31 16:43 ` Adam Beneschan 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 16:34 UTC (permalink / raw) On 31.08.11 18:30, Hyman Rosen wrote: > On 8/31/2011 12:25 PM, Georg Bauhaus wrote: >> On 31.08.11 17:53, Hyman Rosen wrote: >>> On 8/31/2011 2:16 AM, Georg Bauhaus wrote: >>>> In which way would you change T'Value for symmetry? >>> >>> You wouldn't, because the symmetry is false. When you >>> already have an object, being forced to name its type >>> is silly and redundant. >> >> True when there is an object; but what about >> >> (some expression)'Value ? > > Use T(expression)'Value when you must. Even so, X := T'(if condition then 1.2 else 3.5)'Value; is where this is going to end up, I think. At least guessing from the Perl I have been reading recently, and other things that avoid stating things up front, and clearly (such as lambda expressions embedded in function calls argument lists). ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:34 ` Georg Bauhaus @ 2011-08-31 16:43 ` Adam Beneschan 2011-08-31 21:58 ` Georg Bauhaus 0 siblings, 1 reply; 64+ messages in thread From: Adam Beneschan @ 2011-08-31 16:43 UTC (permalink / raw) On Aug 31, 9:34 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > >> True when there is an object; but what about > > >> (some expression)'Value ? > > > Use T(expression)'Value when you must. > > Even so, > > X := T'(if condition then > 1.2 > else > 3.5)'Value; Hang on... doesn't the argument of 'Value need to be a string? I think this conversation took a wrong turn up there---you all meant 'Image, right? -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:43 ` Adam Beneschan @ 2011-08-31 21:58 ` Georg Bauhaus 2011-09-01 7:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 21:58 UTC (permalink / raw) On 31.08.11 18:43, Adam Beneschan wrote: > On Aug 31, 9:34 am, Georg Bauhaus<rm.dash-bauh...@futureapps.de> > wrote: > >>>> True when there is an object; but what about >> >>>> (some expression)'Value ? >> >>> Use T(expression)'Value when you must. >> >> Even so, >> >> X := T'(if condition then >> 1.2 >> else >> 3.5)'Value; > > Hang on... doesn't the argument of 'Value need to be a string? I > think this conversation took a wrong turn up there---you all meant > 'Image, right? OK, yes, I was too, uh, quick, I meant "1.2" and "3.5 and so on. I'll like the polymorphing Value function best. But Dmitry mentions objects as the result of parsing. To me, this seems more about persistent objects than about something that assists newcomers with quickly writing values (of numbers and of enums) in and out. Isn't persistence better served by 'Output and 'Input? Isn't part of the argument about the gap between untagged and tagged types? Rather than changing 'image and 'value, some Ada effort, IMHO, is better directed towards the creation of a flexible, portable tracing package, if tracing seems to dominate the use cases of quick 'Img. Would it work? Starting from: procedure P ... X : ... begin ... put_line (current_error, "In P, value X is=" & T'image(X)); I'd imagine a portable compiler magic package: package Source_Info is ... trace : Source_Info.T; Trace.Set_Output (Current_Error); procedure P ... X : ... begin ... Trace.Debug ("value X is=", X); I am assuming that the compiler will be determining procedure P's full name, and can either infer the type of X and then select or synthesize a suitable transformation function, or will ask the user for assistance as necessary. The output format can be configured, etc. I cannot imagine a project where such a package would not be used. Maybe it is irritating that there should be procedures that have more magic than others. Some syntax should help lessen the surprise. A magic trace package is even easier to use for newcomers and programmers alike. It is also portable, unlike 'Img. Fancy words like "compiler assisted code injection" etc. will allow marketing. Come to think of it, Eiffel has a reserved word, "debug", not sure about compiler magic for source info. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 21:58 ` Georg Bauhaus @ 2011-09-01 7:59 ` Dmitry A. Kazakov 0 siblings, 0 replies; 64+ messages in thread From: Dmitry A. Kazakov @ 2011-09-01 7:59 UTC (permalink / raw) On Wed, 31 Aug 2011 23:58:31 +0200, Georg Bauhaus wrote: > To me, this seems more about persistent objects than about > something that assists newcomers with quickly writing values > (of numbers and of enums) in and out. Isn't persistence better > served by 'Output and 'Input? > > Isn't part of the argument about the gap between untagged and > tagged types? ... and a gap between no-MD and the MD for some built-in operations. 'Image and 'Output are two instances of some MD operation which renders a value of type T1 onto the context of type T2. > I'd imagine a portable compiler magic package: Add has too much magic already. The magic you really need for tracing is source code views, so that you could see the code with tracing insertions and without them. Usually tracing is developed ad-hoc as a part of debugging efforts and then removed, reinserted, removed and so on. It is quite boring. A more managed approach could be, for each use test, tracing insertions kept separately from the source code to be used when necessary. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue (was: Address and bit mask) 2011-08-31 6:16 ` The simple Image issue (was: Address and bit mask) Georg Bauhaus 2011-08-31 14:44 ` The simple Image issue Dmitry A. Kazakov 2011-08-31 15:53 ` The simple Image issue Hyman Rosen @ 2011-08-31 16:08 ` Adam Beneschan 2011-08-31 16:53 ` The simple Image issue Simon Wright 2011-08-31 20:33 ` Georg Bauhaus 2 siblings, 2 replies; 64+ messages in thread From: Adam Beneschan @ 2011-08-31 16:08 UTC (permalink / raw) On Aug 30, 11:16 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > > The most annoying is that you have to specify the [sub]type T'Image(X). It > > should have been X'Image or Image(X). > > In which way would you change T'Value for symmetry? I think if we wanted symmetry, we'd rename 'Value to X'Egami. Or maybe X'egamI? egamI'X? I think Hyman is right on this one. -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:08 ` The simple Image issue (was: Address and bit mask) Adam Beneschan @ 2011-08-31 16:53 ` Simon Wright 2011-08-31 17:02 ` Hyman Rosen 2011-08-31 20:33 ` Georg Bauhaus 1 sibling, 1 reply; 64+ messages in thread From: Simon Wright @ 2011-08-31 16:53 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > On Aug 30, 11:16 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > wrote: > >> > The most annoying is that you have to specify the [sub]type T'Image(X). It >> > should have been X'Image or Image(X). >> >> In which way would you change T'Value for symmetry? > > I think if we wanted symmetry, we'd rename 'Value to X'Egami. Or > maybe X'egamI? egamI'X? I think Hyman is right on this one. > > -- Adam And then we'll have case .. esac, do .. od, if .. fi etc (and even while .. elihw which I don't think has been used before :-) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:53 ` The simple Image issue Simon Wright @ 2011-08-31 17:02 ` Hyman Rosen 0 siblings, 0 replies; 64+ messages in thread From: Hyman Rosen @ 2011-08-31 17:02 UTC (permalink / raw) On 8/31/2011 12:53 PM, Simon Wright wrote: > And then we'll have case .. esac, do .. od, if .. fi etc (and even while > .. elihw which I don't think has been used before :-) So now, the obligatory reference to "_do_ CONSIDERED _ob_VIOUSLY _odd_ IN THREE DIMENSIONS". <http://www.deepdyve.com/lp/association-for-computing-machinery/do-considered-ob-viously-odd-in-three-dimensions-qOVIAyAuG4> ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: The simple Image issue 2011-08-31 16:08 ` The simple Image issue (was: Address and bit mask) Adam Beneschan 2011-08-31 16:53 ` The simple Image issue Simon Wright @ 2011-08-31 20:33 ` Georg Bauhaus 1 sibling, 0 replies; 64+ messages in thread From: Georg Bauhaus @ 2011-08-31 20:33 UTC (permalink / raw) On 31.08.11 18:08, Adam Beneschan wrote: > On Aug 30, 11:16 pm, Georg Bauhaus<rm.dash-bauh...@futureapps.de> > wrote: > >>> The most annoying is that you have to specify the [sub]type T'Image(X). It >>> should have been X'Image or Image(X). >> >> In which way would you change T'Value for symmetry? > > I think if we wanted symmetry, we'd rename 'Value to X'Egami. Or > maybe X'egamI? egamI'X? I think Hyman is right on this one. Yes, symmetry is false along several axes. Point taken along these. I do notice the several Egs. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 16:08 ` milouz 2011-08-30 16:45 ` Georg Bauhaus @ 2011-08-30 19:37 ` Martin 1 sibling, 0 replies; 64+ messages in thread From: Martin @ 2011-08-30 19:37 UTC (permalink / raw) On Aug 30, 5:08 pm, milouz <a.micheli...@gmail.com> wrote: > Thank you very much for all your answers ! > They are all very detailed and I feel that I have a better grasp of > how to program with Ada now. But something still puzzles me... > > I'm ok when Adam B. says: > > > asking "How do I write this C code in Ada" is the WRONG approach. > > But, let me develop... > In C, it's rather easy to know how to do something because 1/ the > langage is so simple and 2/ there are some many helpful resources > (K&R, glibc source code or whatever else, man pages, Stevens's > books...). I talk here about C but it's rather the same with Python, > Perl, C++ or Java. > > In Ada, I found nothing similar and even finding howto do a kind of > 'printf("%x"...)'... hum, sorry... displaying an Integer in hexa, is > difficult. The ARM is a load of 800 pages with no example (it's a > reference manual. how would learn C by reading ISO/CEI 9899:1999 ?). > J.Barnes book might be great but... waiting 571 pages to learn how to > display "hello, world" on a screen is a bit discouraging. > > Don't get me wrong, I'm convinced Ada is great. But what is the proper > way to learn Ada ? Start by heading to http://www.adaic.org/learn/ and http://www.adaic.org/learn/materials/#ada_95_books On that last page there are 3 Ada95 ebooks - that's a start! :-) Also wiki has lots of links (http://en.wikibooks.org/wiki/ Ada_Programming including http://en.wikibooks.org/wiki/Ada_Programming/Basic) is or Rosetta (http://rosettacode.org/wiki/Category:Ada) may be useful. HTH -- Martin ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 15:20 ` tmoran 2011-08-30 16:08 ` milouz @ 2011-08-30 16:32 ` Simon Wright 2011-08-31 7:55 ` Ludovic Brenta 1 sibling, 1 reply; 64+ messages in thread From: Simon Wright @ 2011-08-30 16:32 UTC (permalink / raw) tmoran@acm.org writes: >> for Aligned_Char'Alignment use 16#1000#; >> ... >> alignment.adb:6:35: warning: suspiciously large alignment specified for "Aligned_Char" > I don't see it right now, but didn't someone say we want 8 byte > alignment, ie 2#1000#, not 16#1000#? I don't think so; milouz just wrote ALIGN_MASK. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 16:32 ` Simon Wright @ 2011-08-31 7:55 ` Ludovic Brenta 0 siblings, 0 replies; 64+ messages in thread From: Ludovic Brenta @ 2011-08-31 7:55 UTC (permalink / raw) Simon Wright wrote on comp.lang.ada: > tmo...@acm.org writes: >>> for Aligned_Char'Alignment use 16#1000#; >>> ... >>> alignment.adb:6:35: warning: suspiciously large alignment specified >>> for "Aligned_Char" >> I don't see it right now, but didn't someone say we want 8 byte >> alignment, ie 2#1000#, not 16#1000#? > > I don't think so; milouz just wrote ALIGN_MASK. I think it was I who gave 2**3 as an example value. I was careful to use a notation that minimizes the risk for typos and thinkos. -- Ludovic Brenta. The enabler benchmarks the portfolio, while the clients 200% achieve the leveraged and accepted interpersonal skills at the end of the day. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 9:14 ` milouz 2011-08-30 10:34 ` Ludovic Brenta 2011-08-30 10:40 ` Simon Wright @ 2011-08-30 12:35 ` Georg Bauhaus 2011-08-30 13:03 ` Georg Bauhaus 2011-08-30 15:14 ` Adam Beneschan 4 siblings, 0 replies; 64+ messages in thread From: Georg Bauhaus @ 2011-08-30 12:35 UTC (permalink / raw) On 30.08.11 11:14, milouz wrote: > Hum... well... I still do not know how to do some simple arithmetic > with address. As has been said, addresses are addresses of something. The "something" which your pointers will refer to can be addressed, aligned, and laid out very specifically using the attribute functions and packages mentioned. OTOH... > So, let me give you an example in C : > > p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); The only address arithmetic in there is ... I'm not sure, have you got the parentheses right? Assuming this from the Linux kernel source: /* * Round up the ptr to an 8-byte boundary. */ #define ALIGN_MASK 7 static inline void *align_ptr(void *ptr) { return (void *) (((size_t) (ptr + ALIGN_MASK)) & ~ALIGN_MASK); } (Which, incidentally, gives test.c:8:34: warning: pointer of type �void *� used in arithmetic) Assuming your program cannot control alignment using 'Alignment, layout specifications, and offsets etc, as Ludovic has shown. Cannot perform arithmetic on addresses using this function from System.Storage_Elements: function "+"(Left : Address; Right : Storage_Offset) return Address; Also assuming that you want exactly C's pointer arithmetic, copying C's rules, relying on void* casts, and not use Ada facilities for a reason. (Side note: C's pointer arithmetic and alignment are not defining what's in the hardware, storage elements are not defined in C WRT size etc; C refers to hardware and compiler for further reading. That's somewhat less so in Ada.) Then Interfaces.C.Pointers is your friend, for helping with writing C in Ada, including the necessary C pointer arithmetic functions, such as function "+" (Left : in Pointer; Right : in ptrdiff_t) return Pointer; It is also worthwhile searching the compiler docs that state which type corresponds with C's void* on your platform. (System.Address in case of many GNATs.) If the platform allows direct interpretation of the bits of a pointer as an Unsigned_N (no composite pointers, for example), then after Unchecked_Conversion, the bit operations used in align_ptr above would be those of Unsigned_N (with suitable N), named "and" and "not". ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 9:14 ` milouz ` (2 preceding siblings ...) 2011-08-30 12:35 ` Georg Bauhaus @ 2011-08-30 13:03 ` Georg Bauhaus 2011-08-30 15:14 ` Adam Beneschan 4 siblings, 0 replies; 64+ messages in thread From: Georg Bauhaus @ 2011-08-30 13:03 UTC (permalink / raw) On 30.08.11 11:14, milouz wrote: > p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); Incidentally, this is the function that Adam has had in mind, I think: function "mod" (Left : Address; Right : Storage_Offset) return Storage_Offset; pragma Convention (Intrinsic, "mod"); pragma Inline_Always ("mod"); pragma Pure_Function ("mod"); Should be quite close. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 9:14 ` milouz ` (3 preceding siblings ...) 2011-08-30 13:03 ` Georg Bauhaus @ 2011-08-30 15:14 ` Adam Beneschan 2011-08-30 15:59 ` Adam Beneschan 2011-08-31 7:45 ` milouz 4 siblings, 2 replies; 64+ messages in thread From: Adam Beneschan @ 2011-08-30 15:14 UTC (permalink / raw) On Aug 30, 2:14 am, milouz <a.micheli...@gmail.com> wrote: > Ok, thank you very much for all your answers, but I'm not really more > advanced. Let me summarize : > > - my question was about address arithmetic (howto ?) > - Some fellows gave me cues about the use of the > System.Storage_Elements, but without gaving any concrete example. > - Some others just wandered about the need of doing address > arithmetic. > > Hum... well... I still do not know how to do some simple arithmetic > with address. So, let me give you an example in C : > > p = (char*) (((unsigned long)p + ALIGN_MASK) & ~ALIGN_MASK); > > How do you write that in Ada ? It looks like you have a char* and you want to find the address equal to or greater than p that is a multiple of some alignment. I can think of only one application where you would want to do something like that, so I'll give you some ideas about how to accomplish it. But first I want to echo what everyone else is saying: asking "How do I write this C code in Ada" is the WRONG approach. I can't emphasize this strongly enough. The right approach is to ask "What do I want to accomplish?" or "What is this C code accomplishing?", and then "How do I accomplish that in Ada?" Trying to translate C code just does not work. I have seen a lot of absolutely horrendous code in Ada written by programmers who figured out how they would solve their problem in C, and then tried to do a more-or-less literal translation. Please, don't go that way. Anyway, the case I can think of where you'd want to align a pointer upward has to do with memory allocation; you have a pool of memory and want to allocate a chunk of it, but sometimes the chunks have to be aligned on a certain boundary. In other words, writing your own version of malloc(). This is a useful thing to do in Ada, because once you write your own routines for maintaining the memory pool, you can use the "storage pools" feature to hook up Ada's access types and allocator operation to them. But you still have to write the pool maintenance routines. The way I've seen this done is to set up an array of bytes (storage elements): type Pool_Type is array (Natural range <>) of System.Storage_Elements.Storage_Element; for Pool_Type'Alignment use 2048; -- or whatever the maximum possible alignment you -- might need is Pool_Size : constant := 100_000; Pool : Pool_Type (0 .. Pool_Size - 1); subtype Pool_Index is Natural range 0 .. Pool_Size - 1; Now, instead of doing arithmetic on addresses, you keep variables of type Pool_Index to refer to the next available location, keep free lists, etc., and do your alignment arithmetic on those indexes. When you need the address of the pool element at a given index, then use Pool(Index)'Address. But don't do the arithmetic on the addresses. This is a very rough outline. There should be some publicly available code out there that already does storage pool handling, and I think some of the other posters on this thread can point you to that. So if that's the job you're trying to accomplish, I'd suggest you take a look at the existing code for this. If the reason you want to do address arithmetic is something else, though, you're welcome to ask about it, but rather than giving us C code with no context and asking us how to translate it, please give us a bigger-picture description of what you're trying to accomplish and let us give you ideas about that (like I tried to do with the storage pool example). -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 15:14 ` Adam Beneschan @ 2011-08-30 15:59 ` Adam Beneschan 2011-08-31 7:45 ` milouz 1 sibling, 0 replies; 64+ messages in thread From: Adam Beneschan @ 2011-08-30 15:59 UTC (permalink / raw) On Aug 30, 8:14 am, Adam Beneschan <a...@irvine.com> wrote: > type Pool_Type is array (Natural range <>) of > System.Storage_Elements.Storage_Element; > for Pool_Type'Alignment use 2048; OK, I'm still not used to Ada 2012 aspect clauses, so it would be better to say type Pool_Type is array (Natural range <>) of System.Storage_Elements.Storage_Element with Alignment => 2048; if your compiler supports this Ada 2012 feature. -- Adam ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-30 15:14 ` Adam Beneschan 2011-08-30 15:59 ` Adam Beneschan @ 2011-08-31 7:45 ` milouz 2011-08-31 8:35 ` Ludovic Brenta 1 sibling, 1 reply; 64+ messages in thread From: milouz @ 2011-08-31 7:45 UTC (permalink / raw) On Aug 30, 5:14 pm, Adam Beneschan <a...@irvine.com> wrote: > If the reason you want to do address arithmetic is something else, > though, you're welcome to ask about it, but rather than giving us C > code with no context and asking us how to translate it, please give us > a bigger-picture description of what you're trying to accomplish Ok, so I'll try to be more precise. I have to parse a list of chunks which are 4 bytes aligned. Each chunk is like this: [ size | data ] The 'size' field is a 32-bit unsigned integer and it's the size of the whole chunk. The 'data' field has various lenght (>= 1 byte). I can solve that problem in a C-ish style, but I wonder what is the proper way to solve that problem in Ada. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Address and bit mask 2011-08-31 7:45 ` milouz @ 2011-08-31 8:35 ` Ludovic Brenta 0 siblings, 0 replies; 64+ messages in thread From: Ludovic Brenta @ 2011-08-31 8:35 UTC (permalink / raw) milouz wrote: > On Aug 30, 5:14 pm, Adam Beneschan <a...@irvine.com> wrote: > >> If the reason you want to do address arithmetic is something else, >> though, you're welcome to ask about it, but rather than giving us C >> code with no context and asking us how to translate it, please give us >> a bigger-picture description of what you're trying to accomplish > > Ok, so I'll try to be more precise. > I have to parse a list of chunks which are 4 bytes aligned. Each chunk > is like this: > > [ size | data ] > > The 'size' field is a 32-bit unsigned integer and it's the size of the > whole chunk. > The 'data' field has various lenght (>= 1 byte). > > I can solve that problem in a C-ish style, but I wonder what is the > proper way to solve that problem in Ada. If the chunks are contiguous in memory (or, better yet, in a file), my first reaction would be to construct a stream and then use Interfaces.Unsigned_32'Read to read the sizes and Interfaces.Unsigned_X'Read to read the data. Something like: with Ada.Streams.Stream_IO; with Interfaces; procedure Parse (File_Name : in String) is File : Ada.Streams.Stream_IO.File_Type; begin Ada.Streams.Stream_IO.Open (File => File, Mode => Ada.Streams.Stream_IO.In_Mode, Name => File_Name); Parse (Ada.Streams.Stream_IO.Stream (File)); end Parse; procedure Parse (Stream : in Ada.Streams.Stream_IO.Stream_Access) is Length : Interfaces.Unsigned_32; Alignment : constant := 4; Padding_Byte : Interfaces.Unsigned_8; begin Interfaces.Unsigned_32'Read (Stream, Length); declare Data : Ada.Streams.Stream_Element_Array (1 .. Ada.Streams.Stream_Element_Count (Length)); Last : Ada.Streams.Stream_Element_Offset; begin Ada.Streams.Read (Stream, Data, Last); if Last < Length then raise Program_Error with "not enough data in the stream"; end if; -- process Data here end; -- Now read as many padding bytes as necessary to reach the next alignment -- boundary if Length mod Alignment /= 0 then for J in 1 .. Alignment - Length mod Alignment loop Interfaces.Unsigned_8'Read (Stream, Padding_Byte); end loop; end if; end Parse; -- Ludovic Brenta. The Chief Legal Officer globally achieves the industry-standard baseline starting point. ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2011-09-02 17:29 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-29 15:46 Address and bit mask milouz 2011-08-29 16:06 ` Martin 2011-08-29 16:33 ` milouz 2011-08-29 17:47 ` Dmitry A. Kazakov 2011-08-29 17:54 ` Martin 2011-08-29 18:46 ` tmoran 2011-08-29 19:41 ` Ludovic Brenta 2011-08-29 19:54 ` Adam Beneschan 2011-08-30 9:14 ` milouz 2011-08-30 10:34 ` Ludovic Brenta 2011-08-30 10:58 ` Ludovic Brenta 2011-08-30 12:44 ` Georg Bauhaus 2011-08-30 14:04 ` Dmitry A. Kazakov 2011-08-30 16:12 ` Georg Bauhaus 2011-08-30 16:59 ` Dmitry A. Kazakov 2011-08-30 14:52 ` Adam Beneschan 2011-08-30 10:40 ` Simon Wright 2011-08-30 10:44 ` Simon Wright 2011-08-30 15:20 ` tmoran 2011-08-30 16:08 ` milouz 2011-08-30 16:45 ` Georg Bauhaus 2011-08-30 19:31 ` Adam Beneschan 2011-08-30 19:56 ` Dmitry A. Kazakov 2011-08-31 6:16 ` The simple Image issue (was: Address and bit mask) Georg Bauhaus 2011-08-31 14:44 ` The simple Image issue Dmitry A. Kazakov 2011-08-31 15:36 ` Georg Bauhaus 2011-08-31 15:53 ` Dmitry A. Kazakov 2011-08-31 16:23 ` Georg Bauhaus 2011-08-31 16:27 ` Dmitry A. Kazakov 2011-08-31 16:30 ` Georg Bauhaus 2011-08-31 16:50 ` Dmitry A. Kazakov 2011-08-31 20:41 ` Georg Bauhaus 2011-08-31 21:17 ` Robert A Duff 2011-09-01 7:36 ` Dmitry A. Kazakov 2011-09-01 7:46 ` Dmitry A. Kazakov 2011-09-01 9:50 ` Overloading parentheses and type expectations (was: The simple Image issue) Georg Bauhaus 2011-09-02 7:54 ` Overloading parentheses and type expectations Dmitry A. Kazakov 2011-09-02 10:37 ` Georg Bauhaus 2011-09-02 12:40 ` Dmitry A. Kazakov 2011-09-02 16:08 ` Georg Bauhaus 2011-09-02 17:29 ` Dmitry A. Kazakov 2011-08-31 15:53 ` The simple Image issue Hyman Rosen 2011-08-31 16:07 ` Dmitry A. Kazakov 2011-08-31 16:08 ` Simon Wright 2011-08-31 16:26 ` Dmitry A. Kazakov 2011-08-31 16:25 ` Georg Bauhaus 2011-08-31 16:30 ` Hyman Rosen 2011-08-31 16:34 ` Georg Bauhaus 2011-08-31 16:43 ` Adam Beneschan 2011-08-31 21:58 ` Georg Bauhaus 2011-09-01 7:59 ` Dmitry A. Kazakov 2011-08-31 16:08 ` The simple Image issue (was: Address and bit mask) Adam Beneschan 2011-08-31 16:53 ` The simple Image issue Simon Wright 2011-08-31 17:02 ` Hyman Rosen 2011-08-31 20:33 ` Georg Bauhaus 2011-08-30 19:37 ` Address and bit mask Martin 2011-08-30 16:32 ` Simon Wright 2011-08-31 7:55 ` Ludovic Brenta 2011-08-30 12:35 ` Georg Bauhaus 2011-08-30 13:03 ` Georg Bauhaus 2011-08-30 15:14 ` Adam Beneschan 2011-08-30 15:59 ` Adam Beneschan 2011-08-31 7:45 ` milouz 2011-08-31 8:35 ` Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox