Re: Discriminants or Constructor Function for Limited Types

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t5619r$10bc$1@gioia.aioe.org...
> On 2022-05-07 05:26, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:t52nd4$vj2$1@gioia.aioe.org...
>
>>> Because the task type is not composable.
>>
>> Irrelevant. A task can only be safe if it never interacts with no other
>> objects outside of itself.
>
> Not when other objects are tasks, protected objects, active objects, 
> atomic objects.

That's a common fallacy. Such objects are safe only if there is exactly one 
in your system. If there is more than one, various forms of failure are 
possible even if everything is supposely safe by itself. To make them fully 
safe, you have to have strong access ordering (for instance, the onion skin 
model), which no programming language and probably no static tool can 
enforce. (Proof of safety requires verification that no possible program 
flow can cause a race condition.)

...
>> No, I'm just pointing out that retrying is safe by the language. You seem 
>> to
>> think it is not. Servers need such guarentees to avoid denial-of-service
>> issues.
>
> No, the contradiction is that you claim that safe construction is 
> fundamentally impossible and yet concede that it is safe nonetheless.

"Construction" is safe, always has been (it's not a user level thing 
anyway). Initialization is safe unless you use hacks to make it unsafe (but 
that's sadly common). But the only initialization one should be depending 
upon is quite simple.

 ...
> Because the language lacks obvious abstractions like user-defined 
> discriminants. Otherwise I see no logical reason why:
>
>    F : File_Type ("My_Ada_file.adb");
>
> should not work.

It does "work", but such designs put major restrictions on your clients.

A common way my programs are structured is something like:

     declare
        Output_File : Some_File_Type;
     begin
         Create_or_Open_Output (Output_File);
         Write_Output (Output_File, Data);
         ...
         Close_Output (Output_File);
     end;

You can't use such a structure with your design, because you can't pass in 
the unopened file object to open it appropriately (which can take multiple 
attempts depending upon options, file existence, and the like). Another 
design would hide the file object in the package body rather than passing it 
as a parameter. But you can't do that either, since you can't declare the 
object at library-level in this design (you haven't yet processed the 
program's command line, so you don't know what file to open).

You have to resort to using access types and allocators to get the right 
effect. But any ADT design that requires that forces memory management on 
the user (it is necessarily incompatible with letting the language or 
libraries like the containers doing the memory management). Such designs are 
purely evil. :-)

Discriminants are only useful for memory management (to size arrays, to make 
components conditional). Other uses are purely mistakes.

>> Besides forcing virtually all objects to be allocated (since most
>> objects have to live longer than a single subprogram), it doesn't handle
>> cases where outside forces close the object (common in file systems, 
>> GUIs,
>> etc.). You still end up with those error states, you've just complicated
>> creating an object for no benefit at all.
>
> I simplified creating the object by removing states when the object is 
> unusable for no other reason than language design. Cases when the file can 
> be unreadable because of I/O errors have nothing to do with the case when 
> the programmer did not open it.

There is no difference between the state of an object before it is opened 
and the one it is in after it is closed. (And these aren't just error cases, 
as noted by the Windows example.)

>> We initially trying designing Claw Window objects that way, but one had 
>> to
>> handle the case where the user clicks the 'X' (close button) while a 
>> routine
>> is working on the window. Windows closes the window almost immediately, 
>> and
>> the GUI library has to deal with the consequences.
>
> Windows sends WM_CLOSE first.

Sure, but the only thing you can do at that point is make the object 
invalid. You certainly can't make objects that exist and possibly are 
actively being used disappear! And you can't just raise an exception, you 
may not even be operating on that window object at the time.

>> There's little point in obsessing about designs that only work in 
>> academic
>> exercises. Ada tries too hard already to accomadate designs like yours.
>
> On the contrary, it is a very practical software design problem to reduce 
> error sources as much as possible.

An imaginary reduction of errors, since you have the same states that occur 
in other usage scenarios. And for that, you are preventing the object from 
being managed by the compiler, or even usefully composed. Stupid.

                                    Randy.