Re: Discriminants or Constructor Function for Limited Types

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t52nd4$vj2$1@gioia.aioe.org...
> On 2022-05-06 03:53, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:t4vsfi$jtb$1@gioia.aioe.org...
>>> On 2022-05-05 01:49, Randy Brukardt wrote:
>>>
>>>> Those cases that you worry are "unsafe" seem to me to only occur 
>>>> because
>>>> of
>>>> "hacks and workarounds". There's no good reason to do any of those 
>>>> things
>>>> intentionally unless you are using a "hack" to do something dubious in
>>>> the
>>>> first place.
>>>
>>> Is a task component a hack? Well so long there is no tagged task types
>>> aggregation is the only way.
>>
>> Task objects look like a cool language feature, but use beyond the 
>> simplest
>> patterns will get one into a load of trouble (deadlocks, erroneous use of
>> objects, etc.)
>
> 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. But such a task is close to useless - even if 
extensible, since no access to globals is possible (such as networking, file 
systems, etc.). And if there is a use for it, it's easily modeled with 
parallel operations.

You get deadlocks/races/etc from interacting with global objects of any 
kind. It's not possible to make it safe (some mitigation is of course 
possible).

>> Almost all of the correct uses of seen are implementations of
>> the "pool of workers" scheme.
>
> That is a pretty much trivial case. I am talking about things like 
> implementation of extensible types of active 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.).

>> So, very much like writing your own basic data structures from scratch, 
>> this
>> is a feature which is mostly OBE. (Embedded uses are mostly Ravenscar, 
>> and
>> that doesn't allow dynamically started tasks in the first place.)
>
> Which in many practical cases renders it unusable.

I'm not going to try to defend Ravenscar, I'm just stating a fact here.

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

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

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

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

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. (Moreover, if you didn't 
like Windows do that, you would have a very unresponsive GUI, which wouldn't 
meet user expectations.)

> Merits of each design is always up to the programmer. The language must 
> support him whatever design he pursues, which is unfortunately not the 
> case.

There's little point in obsessing about designs that only work in academic 
exercises. Ada tries too hard already to accomadate designs like yours.

                       Randy.