From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!CndO09ueOTz9v5APEGJmiw.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Discriminants or Constructor Function for Limited Types Date: Fri, 6 May 2022 10:48:37 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="32354"; posting-host="CndO09ueOTz9v5APEGJmiw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:63816 List-Id: On 2022-05-06 03:53, Randy Brukardt wrote: > "Dmitry A. Kazakov" 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