Re: Mixing OO and DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 16 Feb 2008 16:04:07 +0100
Message-ID: <47b6fa98$0$14360$e4fe514c_at_news.xs4all.nl>


Dmitry A. Kazakov wrote:
> 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.
Interesting.
Ada is one of the languages I hoped to learn, but never got around to actually use.
Does it use (something like) type inference?
http://en.wikipedia.org/wiki/Type_inference 's (incomplete) list does not currently include Ada.

I'll keep this claim in my luggage.

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

Yes, we don't want values to mutate.
Circles and ellipses. Couldn't we keep this can closed for now?

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

Why not indeed.
Darren Duncan's work may affect this.
http://search.cpan.org/dist/Language-MuldisD/

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

So we can't record facts containing computed data. Where did this go wrong?

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

Only most of it. The township talks with the traffic engineers, with the bridge builders and with both - sometimes via proxy (projectmanager).

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

No, that won't work. Inputs do not need to be meaningful (have values/symbols associated with informal denotations) in order to be acceptable to processes. Good enough for IPO, not for IDO.

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

'process' is not specific enough.

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

No, the informal understanding is to prune useless formalisms as early as possible (but even 'certain level' is suspect here as it suggests measurability).

Reality check, if you will - not marketing.

--
What you see depends on where you stand.
Received on Sat Feb 16 2008 - 16:04:07 CET

Original text of this message