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>
>
> 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.
>
> Yes, it would be difficult to analyse languages otherwise, but see below.
>
>
> 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.)
>
> 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?
>
> For data are [incomputably] recorded [incomputable] facts...
>
> 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.
>
> Inputs?
>
> 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.
>
> 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?
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?
>>>>> 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?
-- What you see depends on where you stand.Received on Sat Feb 16 2008 - 16:04:07 CET