From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ae9506fd4dcf7090 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-10-24 01:18:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Concatenation and Characters Date: Thu, 24 Oct 2002 10:18:41 +0200 Message-ID: References: <3ZTs9.1528$Bd4.11780@dfw-service2.ext.raytheon.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1035447521 29949221 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:30088 Date: 2002-10-24T10:18:41+02:00 List-Id: On Wed, 23 Oct 2002 14:39:47 +0000 (UTC), Georg Bauhaus wrote: >Dmitry A. Kazakov wrote: >: >: semantics check => halting problem > >halting problem => infinite program/data size >(otherwise just hard work, may take too long or not) Right. And well, formally, there is no difference between Assembler and Ada. (:-)) >: In this case "bowl" and "filled" have different semantics. "bowl" can >: be left uninitailized (I assume that "glass" isn't controlled), >: "filled" shall be always set. So I wished that this difference would >: be exposed through the syntax. Which way, it is another question. > >But which way is there to satisfy any request made this way? >Is there any way to be sure that bit(n) of memory(k) or >register(m) will be "valid", so filled does reflect what it was >intended to reflect? >As you said, that's difficult, or worse than that, right? I said only that the difference should be made visible. Should we apply a reasoning like above to the access types, we could claim that all that one need is "void *", because there is no way to ensure that in all cases an X of "type X is access all Y" really points to an Y. >: then the compiler would complain that this form of parameter >: specification is allowed for only the types having initial values. > >Ah, o.k., but can this be done for deeply nested specifications? Of course. The rule could by very primitive: If a type has no default constructor, then all [non-imported] variables and out parameters of the type shall be "initialized" by either a value or the box <>. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de