Re: Why no Ada.Wide_Directories?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 21 Oct 2011 14:53:11 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 20 Oct 2011 19:35:21 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:

>>> What's missing from Interface type introduced with Ada 2005 ?
>>
>> 1. Most Ada types do not have interfaces
> Eiffel has this, and this is 1) not perfect (may lead to performance  
> issue) 2) rarely used in practice

There is no performance loss.

>> 2. Ada interface cannot be inherited from a concrete type
> You can have a concrete implementation, why is that not enough ?

Because it is not what required: you have a concrete type and want to name
its interface to inherit from, only the interface or its part.

>> 3. Ada interface cannot have implementation
> Derived types can. Why is that a trouble is one inheritance level is  
> purely abstract ?

Why I am forced to have it? If you have a reason, the implication is that
*each* type must have two declarations: the interface and the type itself.
Note that this does not solve the problem, because it would not give
partial interfaces.

The problem is fragile design: you don't know in advance all interfaces the
users of the package might you later on. It is very bad for large system
design.

>> 4. Ada interface does not support ad-hoc supertypes
> Can you tell more with an example ? (I don't know what supertypes are)

If A is a subtype of B, then B is a supertype of A. Subtype imports
operations, supertype exports them.

Ad-hoc means that you can hang on supertypes on existing types, e.g. coming
from a library, which cannot be changed. Doing so you could bring such
unrelated types under one roof, e.g. to be able to put them into a
container etc.

>> Not an issue. Scalar types may have interfaces at zero time/space cost. You
>> don't need to embed tag into by-value types.
> This is possible indeed, but at the cost of separate compilation.

It is possible without that.

>>>> Any syntax sugar (prefix notation, infix operations,
>>>> assignments, indexing, member extraction, aggregates, entries,
>>>> attributes) shall be operations.
>>> Are you sure you are not confused between concrete syntax and abstract
>>> syntax ?
>>
>> I don't understand this. The problem is that, for example, for the record
>> type T and its member A, the ".A" is not the operation of T, because record
>> is not an interface. A'First is not an operation of array. ":=" is not an
>> operation (doubly dispatching) of its left and right sides etc.
> 
> Same feeling as above. Seems you are looking for something which is higher  
> level than Ada is.

It is not higher level, it is just regular language. Ada 83 was designed in
the times when type systems were pretty fresh stuff. It bears marks of
elder languages which had only built-in types.

> May  
> be worth to recall Ada is not a modeling language, but an implementation  
> language with features to enforce safety as much as possible.

You mean that lacking constructors, user-defined assignment, safe
finalization adds something to safety? That must be a very strange kind of
safety then...

>>> This is not a language topic, instead, a technology level topic. I feel
>>> runtime check is a reasonable fall-back for what cannot be statically
>>> checked in th actual state of the technology.
>>
>> No, it is inconsistent and unreasonable. Static checks are meant to  
>> detect bugs. Bug is either there or not, independently on whether the  
>> program is running, not running, will ever run.
> Easy to say, less to do. You did not demonstrate this is not related to  
> actual technology, you just complained it is not as you wish.

No, I complained that self correctness check is inconsistent.

As for raising exceptions from run-time checks, that plague is well known
to anybody who ever used access types. ARG keeps on struggling to repair
the damage made in Ada 95, while breaching another, bigger hole in the
language...

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