Address and bit mask

Address and bit mask

[milouz]

How do you make a binary operation (and, or, etc.) in Ada on an
Address type in a rather portable way ?

Re: Address and bit mask

[Martin]

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

Re: Address and bit mask

[milouz]

> 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.

Re: Address and bit mask

[Dmitry A. Kazakov]

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

Re: Address and bit mask

[Martin]

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

Re: Address and bit mask

[tmoran]

> 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.

Re: Address and bit mask

[Ludovic Brenta]

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.

Re: Address and bit mask

[Adam Beneschan]

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

Re: Address and bit mask

[milouz]

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 ?

Re: Address and bit mask

[Ludovic Brenta]

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.

Re: Address and bit mask

[Simon Wright]

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#
$

Re: Address and bit mask

[Simon Wright]

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.

Re: Address and bit mask

[Ludovic Brenta]

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.

Re: Address and bit mask

[Georg Bauhaus]

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".

Re: Address and bit mask

[Georg Bauhaus]

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.

Re: Address and bit mask

[Georg Bauhaus]

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.

Re: Address and bit mask

[Dmitry A. Kazakov]

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

Re: Address and bit mask

[Adam Beneschan]

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

Re: Address and bit mask

[Adam Beneschan]

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

Re: Address and bit mask

[tmoran]

>    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#?

Re: Address and bit mask

[Adam Beneschan]

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

Re: Address and bit mask

[milouz]

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 ?

Re: Address and bit mask

[Georg Bauhaus]

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.

Re: Address and bit mask

[Simon Wright]

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.

Re: Address and bit mask

[Georg Bauhaus]

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;

Re: Address and bit mask

[Dmitry A. Kazakov]

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

Re: Address and bit mask

[Adam Beneschan]

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

Re: Address and bit mask

[Martin]

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

Re: Address and bit mask

[Dmitry A. Kazakov]

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

The simple Image issue (was: Address and bit mask)

[Georg Bauhaus]

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?

Re: Address and bit mask

[milouz]

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.

Re: Address and bit mask

[Ludovic Brenta]

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.

Re: Address and bit mask

[Ludovic Brenta]

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.

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Georg Bauhaus]

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;

Re: The simple Image issue

[Hyman Rosen]

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.

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue (was: Address and bit mask)

[Adam Beneschan]

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

Re: The simple Image issue

[Simon Wright]

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!)

Re: The simple Image issue

[Georg Bauhaus]

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 :-)

Re: The simple Image issue

[Georg Bauhaus]

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 ?

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Georg Bauhaus]

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"? :-)

Re: The simple Image issue

[Hyman Rosen]

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.

Re: The simple Image issue

[Georg Bauhaus]

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).

Re: The simple Image issue

[Adam Beneschan]

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

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Simon Wright]

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 :-)

Re: The simple Image issue

[Hyman Rosen]

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>

Re: The simple Image issue

[Georg Bauhaus]

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.

Re: The simple Image issue

[Georg Bauhaus]

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?

Re: The simple Image issue

[Robert A Duff]

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

Re: The simple Image issue

[Georg Bauhaus]

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.

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Re: The simple Image issue

[Dmitry A. Kazakov]

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

Overloading parentheses and type expectations (was: The simple Image issue)

[Georg Bauhaus]

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.

Re: Overloading parentheses and type expectations

[Dmitry A. Kazakov]

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

Re: Overloading parentheses and type expectations

[Georg Bauhaus]

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.

Re: Overloading parentheses and type expectations

[Dmitry A. Kazakov]

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

Re: Overloading parentheses and type expectations

[Georg Bauhaus]

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.

Re: Overloading parentheses and type expectations

[Dmitry A. Kazakov]

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