Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Sat, 16 Feb 2008 14:00:50 +0100
Message-ID: <8l1qnemjudyn$.1uq6g784vxt0k.dlg_at_40tude.net>


On Sat, 16 Feb 2008 01:44:13 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:

>> mAsterdam wrote:
>>> Dmitry A. Kazakov wrote:
>>>> mAsterdam wrote:
>>>>> ... Which primitive elements does your formal system have?
>>>> Value, type, variable, operation.
>>> That looks rich enough to get somewhere.
>>>
>>> Somewhat OT to this thread - just because I am curious:
>>> do you have a reference to definitions/descriptions of how these act 
>>> together you consider worthwhile?
>> 
>> Date's definitions were OK for values and types. 

>
>> Any value has exactly one type. 

> We know that doesn't work in practise, but that may be due to the poor
> type systems (or their implementations) in use. Maybe it works in
> theory and just not yet in practise - I really don't know.

It does in practice. For example, Ada's type system has this property.

> Anyway, your statement does sort of draw type into the basics
> of the common ground as well, no?

Yes, it would be difficult to analyse languages otherwise, but see below.

> For precision: I do not need to
> accept "Any value has exactly one type." in order to accept blurk.

You don't need it, because for any type system which does not possess this property there exists an equivalent type system which does. We just look how the given multi-typed value is used in each context and assign some type from the set of its types to it, after making appropriate types conversion when the type changes. I.e. in such a system values will mutate (their types will).

(Which is the reason why such systems are bad. We don't want values to mutate.)

>>>>>> Bad. It means that you have to formalize "memorize" in some quite tricky
>>>>>> way. Honestly I don't know what could be the difference between "memorized
>>>>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>>>>>> so on.
>>>>> Are you suggesting π is data?
>>>> Yes. But you can take some P(pi)=true instead.
>>> Or R(P(π)) - packaging a symbol/value doesn't make it data.
>>> In order to be data it should convey a fact, relevant in a
>>> sense outside the formal system, i.e. an observation, or the basis
>>> for a decision.
>> 
>> Then I see no disagreement anymore. Is all that rant going on for years
>> between c.d.t and c.o just about what to feed to the beast?

>
> Heh. Could it be?

So my impression is. Because I don't see any reason why RA could/should not be described in terms of types. It is a valuable formal structure, why not to model it?

>>>> And, equivalently, you cannot describe
>>>> recording in terms of either data or facts.
>>> Yep, that's the fate of primitives and semi-primitives.
>> 
>> In other words being recorded / data is incomputable.

>
> Being recorded - maybe, but data - why not?

For data are [incomputably] recorded [incomputable] facts...

>>>> But I see no disagreement in the core issue: 
>>>> a formal system does not operate meanings.
>>> I see no agreement to the core issue:
>>> A formal system needs to support meaning to be useful.
>> 
>> "To support" needs to be defined. 

>
> No, it merely needs to be understood. A definition is neither
> a necessary nor a sufficient conditon for understanding.
> It may sharpen it, and it may assist in formalizing the understanding.
>
>> If you mere mean self-consistency or Turing-completeness, then it is OK. 

>
> It is not what I meant.
> In fact I wonder how you arrived to think that is what I meant.
>
>> If you mean something finer than that, you have to say what. 

>
> Nothing finer. Coarser if anything.
> What is the raison d'être of the structure of a bridge?
> That's easy: it supports the substance of the parts of the bridge
> to interact such that the bridge can do what it is designed for: carry
> traffic without blocking what is underneath. Take away the purpose of
> the bridge, take away the substance, either way the structure is futile.

True, but I think you are mixing civil engineering with township management. Could we build bridges on the Moon? The common understanding should lie in civil engineering, leaving purposes of bridges to township.

>> Anyway it would be not "I want data, else there is no
>> common ground." It would be about the structure of the formal system which
>> you wished deploy for what you call data. (Maybe, I could to do it as well,
>> but for something having a different name.)

>
> If that what it takes to get rid of the scarequotes, I have no
> problem with you calling it something else if there are enough
> common associations and isomorphisms - and no blocks.
> Do you have a name in mind? Blurk sucks.

Inputs?

>>>> It is we who assign meanings to the inputs and outputs, and, at
>>>> yet another level of understanding, judge about the formal system as a
>>>> whole in terms of its usefulness, for example.
>>> It is IPO vs. IDO (late 70's debate) all over:
>>>
>>> Input values - Process - Output values: It does not matter what the 
>>> input means, as long as the output is correctly processed from the input.
>>>
>>> Input process - Data - Output process: The input process (datacapture) 
>>> is to be constrained in order to prevent inconsistencies in the data. 
>>> The output process (rendering) should be validated not to corrrupt 
>>> meaning. "You have  01 vacation days left". Ouch - but just within the 
>>> currently acceptable range.
>> 
>> In both cases you constrain a process. So if complementary of views was
>> your point, I think it is invalid. 

>
> 1. This does not follow.
> 2. Complementary views - on what?
>
>> Further if you want to deal with D in
>> IDO, you need a language to describe D. 

>
> Schema + external predicates come to mind.

So you need something that translates schemas, an inference engine to operate them. In my picture, that thing would be equivalent to having some process.

>>>>>> Yes, we cannot reason about meaning while staying 
>>>>>> within the same formal system.
>>>>>> Because you seem to bind data with a meaning (as I do), that immediately
>>>>>> kicks the notion of data out of the formal system. So data do not exist
>>>>>> there. Which is all my point! No data, nothing to worry about.
>>>>> And the result is a hermetic system as useful as solipsism.
>>>>> Have some fun there! I'm out waiting until you are bored of it.
>>>> OK, I am back on vacation. How are you going to formalize something which
>>>> cannot be formalized? (:-))
>>> Hey, I am not the one eager to formalize without
>>> a proper, shared, informal understanding.
>> 
>> Neither I am. 

>
> It sure looks that way, even in your post I am replying to now.

I don't insist on formalizing it right now, but I do on that we should keep in mind necessity of doing it in order to be able to sort the mess out. I thought that your remark was about rather temporal aspect. Or do you reject any need of formalization even after certain level of informal understanding?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Sat Feb 16 2008 - 14:00:50 CET

Original text of this message