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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,ac4955b8006bd13c
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.204.152.217 with SMTP id h25mr3735737bkw.3.1338972754173;
        Wed, 06 Jun 2012 01:52:34 -0700 (PDT)
Path: 
 e27ni19364bkw.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 06 Jun 2012 10:52:17 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Q: type ... is new String
References: <jq5i58$qe8$1@speranza.aioe.org> <jqi6qb$oms$1@dont-email.me>
 <82defba0-2d39-4418-b678-ebbefeb105d7@x21g2000vbc.googlegroups.com>
 <4fcccd1f$0$6583$9b4e6d93@newsspool3.arcor-online.net>
 <ljq3c42wn6kg.137fdbql13gf0$.dlg@40tude.net>
 <4fccdd0c$0$6578$9b4e6d93@newsspool3.arcor-online.net>
 <zsk0ul695neq.184hx8ckz554b$.dlg@40tude.net>
 <4fcd20dd$0$9519$9b4e6d93@newsspool1.arcor-online.net>
 <1tr1nuc1xy9mp$.d5s1fz9vuczz.dlg@40tude.net>
 <4fcdc605$0$9524$9b4e6d93@newsspool1.arcor-online.net>
 <1ch26v7folac1$.1gc355i72r55j.dlg@40tude.net>
 <4fcdf97f$0$9521$9b4e6d93@newsspool1.arcor-online.net>
 <b80f8594-0dad-41e8-9dd0-4c08be4cf605@googlegroups.com>
In-Reply-To: <b80f8594-0dad-41e8-9dd0-4c08be4cf605@googlegroups.com>
Message-ID: <4fcf1a41$0$6565$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 Jun 2012 10:52:17 CEST
NNTP-Posting-Host: 9a15e4e3.newsspool3.arcor-online.net
X-Trace: 
 DXC=CVLdM0GS5mAlU`@c^jLCbJMcF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOK5LCKWkH=]UOPCY\c7>ejVHR95BgSC::YK87\;:[4SBC@
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-06-06T10:52:17+02:00
List-Id: <comp.lang.ada>

On 06.06.12 06:09, Shark8 wrote:
> On Tuesday, June 5, 2012 7:20:14 AM UTC-5, Georg Bauhaus wrote:
>> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
>>
>>>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>>>> I am told to produce the most likely information that the
>>>> originator might have intended to send.)
>>>
>>> Bad design. Don't do that.
>>
>> How is producing the most likely information from a piece
>> of data bad design? And who am I to say "I don't do that"?
>
> PHP gives a good answer [by illustrating the wrong way to do it].

So then, what is the right way to do it, taking us back to the
original question? Given that sometimes the ivory tower has
poky offices; given scarce resources, lack of coffee included;
given specifications that have incomplete definitions, are
contradictory, but do exist like gravity, can we still hope for
a set of types that

- can be developed within finite time
- cover all that is needed, now and in the near future
- are computationally efficient
- don't cram a lot into exceptions
- can be changed within finite time (backwards compatibly)

If we can, and if it isn't rocket science, that is, if it
is relatively easy to do, where is the proof of concept?

Or is it more promising to ask programmers to sort things
out so that the usual String based I/O parameter naming
scheme stays?

   type Locally_Abstract_Name is tagged private;
   ...
   -- add any operations the project likes, e.g. "+"

   type Platform is tagged private;

   function Transform
     (Target   : Platform;
      Filename : Locally_Abstract_Name'Class)
   return String;