Re: Discriminants or Constructor Function for Limited Types

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

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.

> Exactly. The idea that everyone wants but simply will not work. At least in
> any sort of imperative language (it might work in a functional language, but
> it's unclear how one gets to globals like networking in such languages - if
> you can't do that safely, you're going nowhere anyway.).

Surely operations can be implemented by entry calls or protected calls. 
The language lacks rather obvious means of delegation to ease that for 
the programmer as well as a sane initialization protocol to be able to 
start and stop a task component or [impossible now] task parent.

> ...
>> That is an awful and unsustainable design, because you consider
>> initialization magically separated from construction.
> 
> "Construction" is something that the compiler does (allocating the needed
> memory for the object). It doesn't have anything to do with the (logical)
> contents.

Which is simply unacceptable for a language promoting abstract data types.

> ...
>>> On top of that, the language guarentees that all
>>> (controlled) objects that are initialized will get finalized (even when
>>> exceptions happen),
>>
>> Here you contradict yourself.
> 
> 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.

>>> You can handle the exception and
>>> retry.
>>
>> This is not the intended use of exceptions. Exception per definition
>> indicate a program state that cannot be handled locally.
> 
> "Retry" at a high level. For instance, in the web server, it means trying to
> process another connection.

At a very low level, because the language require an object declaration 
to succeed only in the case of a controlled type.

It does not require that for other types. E.g.:

    type Funny (X, Y : Integer) is record
       Z : Integer := X / Y;
    end record;

    begin
       declare
          F : Funny (A, B);
       begin
          null;
       end;
    exception
       when Constraint_Error =>
          Put_Line ("Sorry");
    end;

This is just fine, initialization of F may fail with Constraint_Error, 
no need to invoke Program_Error.

> One doesn't necessary retry the same operation
> (that doesn't make a ton of sense anyway, since it is likely to fail the
> same way). An exception doesn't necessarily mean the program is failed, only
> the one operation.

One does in the case of controlled types. The retry shall happen in 
Initialize for other types it can happen outside.

> ...
>> The importance of failed construction can be easily seen of the design of
>> Ada 83 File_Type. Since Ada 83 library uses initialization never fails
>> approach, File_Type must have unusable states, like when the file is not
>> open and dozens of operations to deal with these states in the client code
>> as well as all sorts of additional errors coming with it as a "bonus."
> 
> Yup. That's pretty much the only way to design such things.
> 
>> An alternative design would exclude unopened files but require object
>> construction faults, e.g. when the file does not exist. Having such file a
>> component will require construction faults of the container type,
>> parameter passing etc.
> 
> That makes an interesting thought experiment, but it doesn't work in
> practice.

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.

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de