Re: Q: type ... is new String

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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;