Re: Reprise: 'in out' parameters for functions

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

Wojtek Narczynski wrote:

>> This has nothing to do with abstraction inversion.
> 
> Would you please take care to explain to me, what abstraction
> inversion is, according to you? For me abstraction inversion is when
> you need to build low level primitives from high level primitives
> (built on low level primitives), because the high level primitives are
> not expressive enough.

or because of using them in an inappropriate way?

However it is questionable, whether protected objects have a higher level of
abstraction than semaphores. They are more generic but no less fundamental.

>> The problem here is that Ada does not have multiple
>> protected actions.
> 
> Google has not heard of "multiple protected actions", neither have I.

ARM 9.5.1 defines "protected action"

> But I think know what you mean, for my own needs I was calling this
> "compound protected". It seems to require proper tail recursion to
> work.

What I meant is the following. Presently one can define an entry to only of
one protected object or task.

Provided that:

1) protected object and tasks would be tagged (inheritable from);
2) multiple inheritance would be supported;
3) entries, procedures and functions would be primitive operations;
4) functional notation would be permitted (instead of prefix notation)

one could have entries of multiple protected objects and tasks. A call to
such entry would start multiple protected actions (one per each protected
object parameter) and multiple rendezvous (one per each task object
parameter). Could we agree that 1-4 is a damn *lot* of work?

BTW, for your protected counters example, (4) would be enough:

protected type Counter is
   procedure Inc; -- Increments this counter
private
   Value : Integer := 0;
end Counter;

procedure Inc_One (First : in out Counter);
   -- Same as Inc, but uses functional notation
procedure Inc_Two (First, Second : in out Counter);
   -- Increments two counters atomically, starts two protected actions,
   -- one per argument

> At least we seem to agree that Ada concurrency features also have
> warts.

I do not see them as warts. Nothing is inherently wrong with them. They
might be extended in a consistent way to make the language more regular
(see 1-4). Make an AI and send it to ARG! (:-))

>> This is wrong:
>> 
>> http://home.t-online.de/home/Christ-Usch.Grein/Ada/Dimension.html
>> 
>> The type system is capable to express dimensioned units.
> 
> By "express" I don't mean bent over in an such a way that your
> compiler checked your units for you, nor have your compiler mostly
> check your units for you, nor write yet another compiler to work on
> top of your compiler. I mean have your compiler statically check your
> units for you.
> 
> I am afraid that this link show exactly that I am, unfortunately,
> right. The two compile time solutions are: 1. "Checks in assignments
> concerning physical dimensions are not performed.", 2. From what I've
> been able to understand Macks has a language, which compiles to Ada.

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.

So to solve the problem one should either use tagged types or discriminated
ones. And this indeed works in Ada.

Now to static checks. Nothing in Ada prevents a compiler to from checking
discriminants or type tags statically.

What I see as a real problem is that neither discriminants nor type tags can
be removed from an object if they are statically known. On the contrary
array bounds are indeed removed.

So again, we have more fundamental and complex problem than just "let's
remove a wart".

>> > From the language? For example parameters for exceptions.
>> 
>> How they could have parameters? There are only two ways for dealing
>> with  exceptions. Either 1) all of them are of one [specific] type
>> (maybe an implicit one) or 2) they are of different types (maybe
>> rooted in the same root type [class-wide approach]).
> 
> You seem to be very well educated in Matematics. Thus you know that
> inexistence proofs are among the hardest. Please don't provoke me to
> ask you to proove that there are only two ways of dealing with
> exceptions.

OK, there are only two ways I know of, if you find a third way...

> And once you assume false, you can prove anything.
>
>> Ada has 1), which excludes parameters. If you think that 2) would be
>> better for Ada then solve the following:
> 
> You assumed that the root type for Exception would be tagged record.

See above, either you derive a new type or not. There is no third way.

> Indeed with this assumption it may be hard to maintain the conceptual
> integrity of the language. But I think this level of parametrization
> is an overkill. I'd rather use something like "discriminated records
> with discriminants only".

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.

> Here is a version to start with (which actually compiles and "works"):
> 
> generic
> package Crazy is
>    Bang: exception;
>    function T return Boolean;
> end Crazy;
>
[...]  
>  
> package body Crazy is
>    function T return Boolean is begin return True; end T;
> begin
>    raise Bang( Hard, Urgent, -1);
> end Crazy;
> 
> with Crazy;
> procedure Sample is
>    package Catch_It is new Crazy;
> begin
>    null;
> exception
>    when B : Catch_It.Bang =>

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.

>       -- Here you'd be are able to access the values,
>       -- but not to call anything from the already gone package.
>       -- Regarding scope it is not any differnt from the previous
>       -- example - we were also accessing Bang in hander.
>       Put_Line (B.Severity);
>       Put_Line (B.Urgency);
>       Put_Line (B.Native_Code);
> end Sample;

As I said, because it is in fact (2) it has all its problems:

generic
package Crazy is
   exception Bang (Times : access Integer);
end Crazy;

package body Crazy is
   I : aliased Integer := 0; 
begin
   raise Bang (I'Access);
end Crazy;

> Please note that this actually works in Modula-3, but you are only
> limited to one parameter. Well, all languages have their warts.

This works in C++ too, because all functions and types are global there. I'd
better stick to Ada's way.

> GNAT.Sockets is perhaps the best example how the code could benefit
> from parametrized exceptions. There you have Socket_Error and that's
> it. You need to use compiler specific tricks to extract more info. Or
> you can declare a coule dozen of different exceptions. Or a couple
> hundred, it depends.

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

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