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-Thread: 103376,5c89acd494ea9116 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news4.google.com!news.germany.com!storethat.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Self pointer in limited record From: Georg Bauhaus In-Reply-To: <15hzyyy3soem0.12hn79bwy27zt$.dlg@40tude.net> References: <1183577468.034566.57830@n60g2000hse.googlegroups.com> <1188578849.187422.280620@50g2000hsm.googlegroups.com> <9fy1xoukz1e3$.h574sqmiauri$.dlg@40tude.net> <46d968ee$0$30368$9b4e6d93@newsspool4.arcor-online.net> <137iu0lr82dtb$.wqy3zjz2vr9q.dlg@40tude.net> <46d972e8$0$30384$9b4e6d93@newsspool4.arcor-online.net> <1alyfwaig93sk$.99oy269uon$.dlg@40tude.net> <46d9c138$0$4531$9b4e6d93@newsspool3.arcor-online.net> <1rt8kdcrj6tf.1qgvycc6vh357$.dlg@40tude.net> <46db2bf4$0$7699$9b4e6d93@newsspool2.arcor-online.net> <1188816674.2630.25.camel@kartoffel.vocalweb.de> <9cdmw7k85sey.85sb2t1bjefy$.dlg@40tude.net> <1mbajw59c3eir.jyl8bdp6qvj8.dlg@40tude.net> <1188850449.2630.60.camel@kartoffel.vocalweb.de> <1aza6nzawgcnm.sf76q4dvzw4n$.dlg@40tude.net> <46de8897$0$16115$9b4e6d93@newsspool1.arcor-online.net> <15hzyyy3soem0.12hn79bwy27zt$.dlg@40tude.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1189017071.2630.246.camel@kartoffel.vocalweb.de> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Wed, 05 Sep 2007 20:31:11 +0200 Organization: Arcor NNTP-Posting-Date: 05 Sep 2007 20:30:33 CEST NNTP-Posting-Host: c41a3adb.newsspool1.arcor-online.net X-Trace: DXC=XG\CF7W=NBO78PK[oJ2ng@ic==]BZ:afN4Fo<]lROoRA4nDHegD_]RE9n?^LT\f3?@N[WdgK X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:1760 Date: 2007-09-05T20:30:33+02:00 List-Id: On Wed, 2007-09-05 at 14:04 +0200, Dmitry A. Kazakov wrote: > and you have to fix the point of view before you start to talk about > *an* abstraction. The abstraction can be "dog" or it can be "named thing," > but it cannot be Spike. I fail to see why Spike the dog cannot become an abstract entity of a program. My perception of Spike can be that of a "named thing" with some details abstracted away as I see fit. Assuming a name doesn't turn a thing into atomic information without properties and without behavior. > > Abstraction as a process can be fuzzy, I known you are familiar > > with that? > > If you want to refer to fuzziness and other measures of uncertainty, then > carefully observe that these always brings multiple concurrent choices > with. For example the programmer's choice could include alternative points of view, suggested by the problem description. Each viewpoint can yield a slightly different abstraction when the resulting interfaces, say, are a consequence of more or less emphasis on some of the dog's characteristics. > You simply cannot define either probability or possibility or > whatever else measure on a singleton substrate without trivializing it to > the crisp case. This is non-starter. I have to ask whether by singleton substrate you mean something in the problem description that states one and only one possible quality of a thing. That'll beg the question, of course. > >>> I wonder, though, why then we can still talk about abstract data > >>> type and abstract state machine. > >> > >> Abstract data type is an abstraction of concrete data types. > >> > >> Abstract state machine is an abstraction of concrete state machines. > > > > OK, another interesting definition that refers us to > > the definition of a concrete state machine which I am > > certain is equally interesting, even though it is not given. > > See finite state machine. A finite state machine using packages, being implicit in some subprogram, the formal thing known as a tuple (...) where ..., the UML thing? There isn't just one definition/view/concept of finite state machine... > > There are other sources, not dealing with Ada specifically, > > but mentioning the use of Ada packages for this. > > So what? I don't see any connection. How using ASM as an adjective to the > word "package" could define either? Why define Ada packages in terms of ASMs or vice versa? I'm lost. > The point was "to have one instance" and "to be a FSM" are unrelated. There is a point of view from which the concept "to have one instance" and "to be a FSM" are unrelated. When writing an Ada program, you may have a point of view from which the concept "to have one instance" and "to be a FSM" coincide on a suitable conceptual level. It is the level on which an abstract state machine package is explained. > >>>> But an *abstract* state > >>>> machine is definitely a type that generalizes many concrete state machines. > >>> By what definition of type is an ASM a type that generalizes many > >>> concrete state machines (=what, in Ada terms?)? > >> > >> type State is (...); > >> type Transition_Relation is array (State, State) of Boolean; > >> type ASM is private; > >> function Create (Initial : State; Wiring : Transition_Relation) > >> return ASM; > >> procedure Step (Machine : in out ASM; Input : State); > >> > >> This machine is abstract because its wiring is a parameter (abstracted). > > > > Hm. A singular parameter as a source of abstraction ... not a plural ... > > Plural is addressed to the set of values of that type. So abstraction is all about starting at some type and then saying the thing using parameters of the type is abstract because each parameter will be of a yet unknown concrete kind? Seems like a narrowed view of abstraction.