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,b6e97963d32ee242 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-28 05:36:16 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-FFM2.ecrc.net!news.iks-jena.de!not-for-mail From: Lutz Donnerhacke Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: Wed, 28 May 2003 12:36:15 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: <254c16a.0305210726.485125de@posting.google.com> <3eccdf77$1@epflnews.epfl.ch> <3ecdd296$1@epflnews.epfl.ch> <3ED056CB.8000200@attbi.com> <3ed33506.7272397@news.btclick.com> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1054125375 3599 217.17.192.37 (28 May 2003 12:36:15 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Wed, 28 May 2003 12:36:15 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.ada:37902 Date: 2003-05-28T12:36:15+00:00 List-Id: * Dmitry A. Kazakov wrote: > However, overriding attributes raises an interestring question of making > everything that could appear on the left side of an attribute a first-class > object. Furthermore it allows an envolving solution to the original question: Drop the restriction which attributes are allowed. Several attributes might have a predefined meaning, but other than the predefined attributes might be allowed in Ada200x. So if you want to apply an 'object.method' syntax, do type object ...; procedure method(a : in out object; ...); for object'method use method; done. But there are more important features missing an Ada 95: ************************************************************************ Newsgroups: comp.lang.ada Subject: AdaYY wish list from current projects Organization: IKS GmbH Jena Message-ID: <96ulad$r9e$1@belenus.iks-jena.de> I have three sad problems (and a bonus problem) from my current projects. If they can fixed by a compiler it would be very fine: Problem 1: Pointer of component => Pointer to aggregate In order to mixin a generic list with head nodes not mixed into any other user defined structure I'd need to link not the base data but the mixin itself. Doing so I need to regenerate the whole aggregate pointer from a pointer of a component. Current (not tested) implementation: with System.Address_To_Access_Conversions; generic type Base is tagged limited private; type Mixin is tagged limited private; package Unchecked_Upconversion is type Mixed is new Base with record mix : aliased Mixin; end record; package Mixin_P is new System.Address_To_Access_Conversions (Mixin); package Mixed_P is new System.Address_To_Access_Conversions (Mixed); Call_To_Mix_First : exception; function To_Base (mix : Mixin_P.Object_Pointer) return Mixed_P.Object_Pointer; function To_Mix (mixed : Mixed_P.Object_Pointer) return Mixin_P.Object_Pointer; end Unchecked_Upconversion; with System.Storage_Elements; use System, System.Storage_Elements; package body Unchecked_Upconversion is offset_found : Boolean := False; offset : Storage_Offset; use Mixed_P, Mixin_P; function To_Base (mix : Mixin_P.Object_Pointer) return Mixed_P.Object_Pointer is begin if not offset_found then raise Call_To_Mix_First; end if; return To_Pointer (To_Address (mix) - offset); end To_Base; function To_Mix (mixed : Mixed_P.Object_Pointer) return Mixin_P.Object_Pointer is begin if not offset_found then offset := To_Address(mixed) - To_Address(mixed.mix'Access); offset_found := true; end if; return mixed.mix'Access; end To_Mix; end Unchecked_Upconversion; It's clearly a workaround to fix a missing language feature. Even other solutions (i.e. using Base'Size) are only workarounds which may fail in complex situations (pragma Pack) even more likely. Of course this Conversion may return a Pointer to an invalid aggregate. Problem 2: Defining Byte_Order of record representations My low level networking application has to deal with low and big endian values on the net I want to handle with record representations clauses in order to get the benefits of compiler generated I/O functions. Unfortunly only the numeration of bits in the data may be specified. Values crossing a Storage_Element boundery can not be handled portably. Even worse Storage_Element'Size might not be a multiple of eight. So it's impossible to write portable programs. At the moment I use constructs like the following (introducing new error sources, because they are likely forgotten and a lot of legacy code): for xxx use ( addr1 at 0 range 0 .. 7; addr2 at 1 range 0 .. 7; ); ... addr : Address_Type := Unchecked_Conversion_To_Address ( to_uint16(x.addr1, x.addr2)); if not addr'Valid then ... case addr is ... function to_uint16(low, high : uint8) return uint16 is begin if System.Default_Bit_Order = System.Low_Order_First then return Unchecked_Conversion_To_U16 ((low, high)); else return Unchecked_Conversion_To_U16 ((high, low)); end if; end to_uint16; 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. This attribute must include the conversions above in order to generate better code. Several CPUs does have a maschine language prefix to specify the byte and the bit order (in)depenty, It's only a bunch of hard wired gatters on the chip which should be usable from AdaYY. Problem 3: Static expressions of discriminants in record representations Trying to may a simple data structure like a Pascal string is not possible with Ada95. This is even worse in enviroments where memory mapped I/O contains such structures and must be handled using Atomic and Volatile Pragmas. It would be fine to use the following: type pascal_length is 0 .. 255; type pascal_string(len : pascal_length) is record data : String (1 .. len); end record; for pascal_string use record len at 0 range 0 .. 7; data at 1 range 0 .. 8*len - 1; end record; Additional suggestions are: - limit the restriction to specify discriminats at the very beginning. - 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; ************************************************************************ There is an interesting discussion on the usual archives following this proposal.