Re: Self pointer in limited record

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

On Wed, 05 Sep 2007 20:31:11 +0200, Georg Bauhaus wrote:

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

There exist no information without "behavior." Information is meaningless
in absence of receivers. If Spike barks there is at least a tree here to be
barked at. Barking in vacuum does not work.

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

Yes you can have a set of abstractions and some confidence measure attached
to each. The idea of probability et all theories is that all these
outcomes, events, "focal elements" etc coexist. You cannot prefer any of
them for certain, as you cannot say odd or even before the coin falls. This
cannot be trivialized to certainty. So any model and whatever it predicts,
always boils down to a distribution of confidences and stops there.

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

If you have only one elementary outcome then its probability is trivially
1. You need a surface to smear uncertainty on... (:-))

>>> 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 didn't do that, not my idea.

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

Can I take a protected object or a task to implement either?

(I have no respect to singletons. They might have some sacral meaning for
some OO proponents, but that was always beyond my understanding.)

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

It is not the whole view, just a necessary component of: "one for many."
You can have it with variable vs. values, type vs. values+operations, sets
of types vs. types (classes/generics). I don't object when "many" is in the
problem domain and "one" is in the solution one. It is an abstraction too,
but not so interesting as others.

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