Re: Reprise: 'in out' parameters for functions

[wojtek@power.com.pl (Wojtek Narczynski)]

Hello,

> Sorry, but I still do not get your point. Either Ada features are 1) beyond
> any help; 2) OK, but has to be impoved in some definite way; 3) Excellent.
> It seems that you do not agree with (3). So either (1) or (2) remain. Which
> one?

Depends on the application. For highly concurrent data structures that
would be 1, for tutorials 3. For many applications they are probably
okay. I am talking about concurrency features only now, but other
parts of the language also have their problems. Still, with all the
problems, Ada is  overall the best procedural language I've seen.

---
 
> I gave you an example of a *real* application requiring units (and units
> checks, because surely in any place where the system expects, say, a
> velocity, the operator may give it in any compatible unit: knot, km/h, m/s,
> mph, whatsoever, but not in kPa. So units are indeed checked.)

You could make it unable to enter a wrong unit in the interface. So
this would be ensuring that 'Unit_Error' cannot be raised, rather than
catching and handling it. But it is not always possible, for example
when reading from an untrusted file, so you are right.

> I already mentioned in my  previous post that Ada designers managed to do a 
> similar job with the type String. Carefully observe how Ada deals with 
> statically constrained String subtypes. In my view it is quite possible to 
> deal this way with dimensioned values too.

I've studied your code on units, I admit I should have done that
before engaging in discussion about units with you.

Regards,
Wojtek