Re: Discriminants or Constructor Function for Limited Types

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

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.

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

> 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. Modern embedded 
systems need tasks started upon activation of the system configuration, 
which is no more static. You may not need new tasks during normal 
operation, but you need start and stop tasks in between.

In general, it is a serious distortion of design considering networking 
protocols. Though it is possible to implement a protocol session without 
reserving a task for it, but it would be an extremely unnatural way to 
do. In fact the programmer is forced to re-implement tasking and write 
complex unreadable and unmaintainable state machine code. Lack of 
co-routines for light-weight non-preemptive tasking is yet another 
language problem.

>> Controlled types are hacks, yes, but there is no alternative. You admit
>> that all tagged types (and I would say all types) should be controlled =
>> support user-defined initialization hooks.
> 
> I don't think I said anything about controlled types being hacks.

Of course they are, because Initialize is not a proper way to do safe 
object construction.

>> Exception propagation upon initialization? There is no enforceable
>> exception contracts to fight it.
> 
> But you don't (or shouldn't) care what happens to an object when an
> exception is raised during initialization. The program is wrong, it needs to
> be fixed, end of story.

That is an awful and unsustainable design, because you consider 
initialization magically separated from construction. It is simply 
impossible to have beyond very simple examples. In a normal program an 
object must be constructed using a set of parameters and this frequently 
a quite complex process should be designed in a structured way. Which in 
particular means that parts of construction are re-used and may fail. 
You simply cannot have an atomic construction.

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

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

> What you can't do is use the object that failed for anything, so the
> fact that you don't know if it was fully initialized is irrelevant.

Nobody ever argued for using half-constructed objects. BTW, one of the 
reasons what Initialize is a hack is because it allows and encourages 
such things.

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

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.

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.

> You have a strange idea of language problems. (But of course I've known that
> for a long while; I've written these responses for the benefit of lurkers
> and the OP, not so much to convince you of anything. :-)

Thanks for introducing me! Bowing to the public... (:-))

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