From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,616091a85ff150f1
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-04 09:09:04 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: dewar@gnat.com (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Ada 200X Assertions
Date: 4 Dec 2001 09:09:03 -0800
Organization: http://groups.google.com/
Message-ID: <5ee5b646.0112040909.13a75fce@posting.google.com>
References: <3C0C48BE.3B20F04E@adaworks.com>
 <slrna0p3q9.n1.lutz@taranis.iks-jena.de>
NNTP-Posting-Host: 205.232.38.14
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1007485743 10747 127.0.0.1 (4 Dec 2001 17:09:03
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 4 Dec 2001 17:09:03 GMT
Xref: archiver1.google.com comp.lang.ada:17389
Date: 2001-12-04T17:09:03+00:00
List-Id: <comp.lang.ada>

lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrna0p3q9.n1.lutz@taranis.iks-jena.de>...
>    I'd like to see a additional Byte_Order type and 
>    attribute to specify the
>    most common byte orders indepenent from the used bit 
>    order.

A lot of people want some magic here, but in fact it is
very difficult to design a coherent language feature (i.e.
the step from the rough idea, which has been often
expressed, to a detailed proposal which holds water.

No one has achieved this yet. Someone needs to have something to
propose first. And is not good exhorting
others to work on this, they have and not solved the
problem. I personally don't think you can have a general
solution for many reasons, so the issue is simply whether
you can have a partial solution.

One thing we did in Realia COBOL was simply to have big and little
endian types (e.g. consider allowing bit order to
be specified for integer types). That's quite useful for
some of these cases, but magic is out :-)

>       type pascal_length is 0 .. 255;
>       type pascal_string(len : pascal_length) is record
>          data : String (1 .. len);
>       end record;

Well this is nonsense Ada, so let's try to first correct it
to something that compiles (I wish people would compile
code fragments before posting junk :-)

package z is
       type pascal_length is mod 2 ** 8;
       type pascal_chars is array (pascal_length range <>)         
                                            of character;   
       type pascal_string(len : pascal_length) is record
          data : pascal_chars (1 .. len);
       end record;
end z;                                      

Now the default representation of this in GNAT (and in
any reasonable compiler) is:

for pascal_string'Object_Size use 2048;
for pascal_string'Value_Size use  (((#1 max 0) * 8) + 8) ;
for pascal_string'Alignment use 1;
for pascal_string use record
   len  at 0 range  0 ..  7;
   data at 1 range  0 ..  ((#1 max 0) * 8)  - 1;
end record;

which is exactly what you want (this by the way is output
from the GNAT -gnatR3 switch, and #1 means the value of
the first discriminant.

Yes, it would be nice to have a way of specifying this
for sure, but it is hardly a critical problem in practice.

>       for pascal_string use record
>          len  at 0 range 0 .. 7;
> 	 data at 1 range 0 .. 8*len - 1;
>       end record;

This solution won't fly at all, it is has horrible
implications, since the situations in which expressions
of this kind could be used are very limited, and the list
of rules would be junk. For example, if you allow

            len at 0 range 7+len;

you have a huge mess on your hands.

So your solution here is the wrong solution to the problem.
I would guess it would be good enough to simply be able
to give the static starting position

perhaps something like

         data at 1 range 0 .. <>;

where the meaning of <> is that you will let the
compiler choose. 

> 
>    Additional suggestions are:
>       - limit the restriction to specify discriminats at the very beginning.
>         (currently possible)
>       - limit the restriction to specify discriminats at statically known
>         positions. Allow discriminant dependant discriminant positions.
>       - limit the restriction of cycle free position specifications.
>       - extend this concept to tagged records.
>  
> Problem 4: Single task packages
> 
>    Several algorithms require hard work to deal with multitasking. Most of
>    those algorithms consist of small and short running functions and
>    procedures. On many CPUs those calls can be implemented very efficently
>    using self modifying code. In order to generate such code the compiler
>    has to determine which parts are single task and which might be
>    interrupted. In order to ease this allow the following syntactic shugar
>    constructs:
>        protected package xxx ...
>        protected procedure xxx ...
>        protected function xxx ...
>    which are similar but stronger than:
>        proteced type yyy is
>           procedure xxx;
>        end yyy;
>        y : constant yyy;   -- Singleton
>        procedurce xxx is begin y.xxx; end xxx;