Re: Self pointer in limited record

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

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.