Re: Reprise: 'in out' parameters for functions

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

Wojtek Narczynski wrote:

> Dimitry,
> 
> You silently refused to say what abstraction inversion is according to
> you :-)

We can use your definition if you want. (:-))

>> First of all I do not count compile time solutions for true solutions. A
>> true one would include an ability to work with dimensioned values which
>> units are unknown at compile time. A simpliest possible example is to
>> write a physicist calculator.
> 
> Then we're talking about two distinct things. I am talking about a
> compile time solution only.

Why should they be distinct? The key advantage of Ada strings as compared to
Pascal ones, is that they works in both static and dynamic cases. Why units
should be handled otherwise? How would you then mix both approaches in one
program? In my view a real solution should respond the requirements I
mentioned in another thread answering Russ.

>> OK, there are only two ways I know of, if you find a third way...
> 
> The first way can be viewed as an incarnation of the second.

Surely the second way is more general.

> Or you can ensure that there are no runtime exceptions.

I didn't say that (2) is not solvable. I just invited you to think about it
more deeply, before making some final statements. For example, one could
make the exception object mutating to its parent type, when the exception
type goes out of scope. This would then influnce the language. In which
way? What are the consequences, I mean all consequences, etc.

>> How it differs from (2)? You just replaced the official mechanism of
>> inheritance with some hard-wired other. Discriminants are just special
>> kind of members.
> 
> It differst in that it can be implemented, because there are no
> pointers to inexistent trampolines, only (immutable, integer) values.

Discriminants can be of access types.

>> This won't work. The exception out of Catch_It will be propagated *after*
>> "end Sample". So you cannot catch it here! In any point you could, the
>> type B will be already finalized. So you would have a zombie object of an
>> unexisting type.
> 
> Well, this is how it goes with exceptions. That's why the "type"
> should be limited (in ordinary sense) to only: declaration, raising /
> construction, catching and extracting immutable values in handlers.

Here you create a new class of types, limited in some particular way. Doing
so, you have to precisely define this class, you have to name it, you have
to consider types other than exceptions of being of this class, you have to
give it a formal name for generics and so on and so far. And in the end you
have to answer some newbie, why Ada does it that complex!

>> Why (1) cannot work here? The only real problem with (1) I can see, is
>> that the exception type does not have ranges or other forms of subsets.
>> One need some syntactic suggar to define a set of exceptions which could
>> be then named in "when".
> 
> Feel free to perceive my 'code' as syntactic sugar.

It is not (1) it is (2), which has a lot of problems.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de