Re: Why no Ada.Wide_Directories?

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

Le Thu, 20 Oct 2011 19:35:21 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> No, FP is just too low level: procedural decomposition. Type systems
> correspond to the categories - a better and more capable mathematics =>
> safer design. Another fundamental problem of FP is a wrong premise about
> being stateless. Computing is solely about states. You run a program to
> have its side effects, there is no other reason for doing that.
You should write every thing down you know (your though about Ada, FP, and  
so on). Would be useful to you and others.

>> 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

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

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

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

Feels like to need an even higher level language than Ada is. There are  
some, however most are interpreted language, and are not targeting safety  
(in the wide meaning) as much as Ada too.

> 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.  
SmallEiffel did this, but was relying on overall program analysis, which  
were compiled as a whole. Some other Eiffel implementation using separate  
compilation, could not optimize. If you make it part of the language  
standard, you are imposing implementation requirements beyond the  
reasonable. Very big applications need separate compilation. Although  
attempted and suggested by Bertrand Meyer, Eiffel applications never  
scaled large fine (except with global analysis, but re-compiling a whole  
application whenever something change, although they may be some trick to  
avoid real recompilation of everything, is not an acceptable option for  
Ada niches).

>>> 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. There are some pleasant language in this area, but  
which just end to be cool toys (although still cool to play with ;) ). May  
be worth to recall Ada is not a modeling language, but an implementation  
language with features to enforce safety as much as possible.

>> 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.


Sorry if I've not replied to each point, to keep it short. I often agree  
with many points you sometime raised about Ada. There, I feel you are  
going to far for what Ada is intended to. You are not noticing any  
inconsistencies in existing features, you are requiring new features.


-- 
“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