Re: Why no Ada.Wide_Directories?

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 21 Oct 2011 22:02:55 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> You wrote about the implementation being sufficient, which is evidently
> wrong.
>
> The interface = an array of code points indexed by some cardinal number  
> is
> sufficient. The implementation = Wide_Wide_String is not.
That's what I wanted to mean: array interface implemented with its most  
naive implementation. The interface is good and is Ada side, the  
implementation may vary, and is compiler side.

> Ada does not allow you multiple implementations for this interface  
> forming
> one class of types. Ada does not allow you constrained subtypes of the
> interface, e.g. narrower sets of code points (String), narrower ranges of
> the index (small embedded targets). Ada does not allow you alternative
> implementations like unbounded strings in the same class.

That's not that easy. If you want to restrict the set of code point  
allowed in a container, you must care about preserving class properties. A  
subtype T1 of a type T0, is supposed to be a valid element where a type T0  
is expected. However, if the actual is T1 and the expected type is T0 and  
the object is a target of some operation, then as an example, appending a  
code point outside of the restricted range, while valid with an actual of  
type T0, would be illegal with an actual of type T1. On the contrary, as a  
source T1 will always be valid where a T0 was expected.

Conclusion: the interface could not remain the same, and different  
interface, means different type. Unsolvable (a common pitfall known of  
ancient Eiffel users). That's by the way one of the reason why assertions  
introduced with Ada 2012, are expected to be checked at runtime, because  
to warrant it to be statically valid, would lead to a real nightmare for  
the language maintainers (I keep in mind you don't enjoy runtime check,  
which is OK, if you assume all of the consequences).

> This problem is a *fundamental* problem of the Ada type system. It must  
> be
> addressed if the Ada wishes to stay a strongly typed language.
If address nicely enough (except with some area like String and some part  
of access types) what it provide. Consistency in a narrow range is better  
than a wide range with inconsistencies, and to most people, a narrow range  
which can be reasonably implemented, is better than a perfect thing which  
cannot be implemented. That was one of the error Bertrand Meyer did, when  
he asserted language designers should not bother about whether of not a  
given language property is certain to be implementable. In real life,  
language designers have to care it is, and have to care it is reasonably.

As said in a prior message, such languages already exist, but as far as I  
know, all I played with was either interpreted or inefficient languages  
(and all had names I cannot remember, sorry), which is not OK for Ada (for  
me it's OK if it lacks some purity, as long as it is safe and efficient  
enough).

After all, may be what you need is not Ada! (would not be a shame).

> How so? They are two most used public interfaces of composite types in  
> Ada!
The language does not enforce it, this only occur in the standard library,  
and you remain free to not follow this design and choose your own if you  
wish. Just like the naming convention, I don't enjoy the one of the  
standard package, that does not prevent me from using my own,, the  
language does not enforce anything there.

> BTW the same applies to the numeric types, would you claim them used only
> privately too?
Arguable in theory, not in practice. If it ever is, just use a language  
better suited for your very specific area.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit