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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Musing on defining attributes and the ability to define an
 "abstract type X"-interface.
Date: Sat, 5 Aug 2017 08:25:19 +0200
Organization: Aioe.org NNTP Server
Message-ID: <om3ocg$9mo$1@gioia.aioe.org>
References: <9617c73b-e23e-405b-8544-4d17e7e3ad61@googlegroups.com>
 <okpnfb$9du$1@gioia.aioe.org>
 <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com>
 <87h8y67trd.fsf@jacob-sparre.dk>
 <ae46a44e-ee1e-42f6-ae8d-a02ae012e31d@googlegroups.com>
 <om32rl$ess$1@franka.jacob-sparre.dk>
NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Language: en-US
Xref: news.eternal-september.org comp.lang.ada:47601
Date: 2017-08-05T08:25:19+02:00
List-Id: <comp.lang.ada>

On 2017-08-05 02:17, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:ae46a44e-ee1e-42f6-ae8d-a02ae012e31d@googlegroups.com...
> ...
>> IOW, what I want to do is leverage the language's underlying concepts,
>> making
>> them explicit, and using *THAT* to unify/define what is already (in some
>> sense)
>> required... like how universal_integer attributes require a bignum package,
>> but
>> the language doesn't require its exposure.
> 
> I made a stab at this some years ago (see the discussion of AI12-0021-1);
> the idea was to define a Root_String_Type that all of the others are derived
> from. Some messing around is needed to get literals and conversions. Idea
> being that a routine taking a Root_String_Type'Class parameter could handle
> any text string, with any representation or storage management (i.e.
> unbounded or fixed), without any explicit code.

There are concepts underlying this one.

> I have no idea if there is any interest in pursuing this approach, or some
> similar approach;

Not in this form. Because it is still looks like a hack.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de