Re: Proposal: 6NF

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 16 Oct 2006 23:23:06 GMT
Message-ID: <uvUYg.149316$1T2.119341@pd7urf2no>

vc wrote:
> Jan Hidders wrote:

>> vc wrote:
>>> Jan Hidders wrote:
>>>> vc wrote:
>>> [...]
>>>>> The most familiar to the OOP person expectation of what the type is is
>>>>> based on the LSP where one can substitute objects of type S for objects
>>>>> of type T, S being a subtype of T, without change in behavior.
>>>>> Clearly,  treating Z as subtype of R does not conform the LSP,  because
>>>>> Z is not a subfield of R.
>>>> Depends on what you think of as the thing that is being defined. Is it
>>>> the algebraic structure or is it the set over which the operations are
>>>> defined? In the first case you cannot treat the Z algebraic structure
>>>> as a subtype of the R algebraic structure, but in the second case you
>>>> clearly can.
>>> Hold on.
>> Ok. I'm holding on.
>>
>>> o The set plus some operations over the the set  *is* an algebraic
>>> structure so there is no substantial difference between case one and
>>> case two.  Once again,   this is an example of imprecise language which
>>> one would want to avoid (saying 'set' and meaning 'structure').
>> When I say "the set of integers" I mean "the set of integers" and not
>> "the set of integers plus some operations" which is a tuple and not a
>> set.

>
> When one says "the set of integers", one usually refers to a set of
> things possessing some properties, addition/multiplication/subtraction
> operations obeying certain laws. If one says "the set of integers" and
> excludes one or more operations, then one makes the mistake of
> misnaming the structure one is talking about. You can call the
> structure 'my_private_integers', but it's not the same thing we came
> to love and respect at primary school.
>

>> I get the impression that every time I write "the set of X" you
>> actually read "the algebraic structure that descibes X", which might
>> explain why you think I'm being imprecise.  If I understand you
>> correctly you don't accept that "the set of X" is actually a meaningful
>> concept? Correct?

>
> It depends on what the set of X is. If it's just a collection of three
> thing without any known properties, then the most one can say is that
> "it's a set of three things". Re. integer, see above, you cannot
> divorce integers from their properties because what you get is no
> longer integers. By saying "the set of integers, you implicitely
> accept all the qualities the integers might have, good or bad ;)
>
> >

>> If that is the case then let us concentrate on that question. Agreed?
>>

>
> OK.
>

>>>> Note that Liskov and Wong themselves defined the principle
>>>> as:
>>>>
>>>> Let q(x) be a property provable about objects x of type T. Then q(y)
>>>> should be true for objects y of type S where S is a subtype of T.
>>>>
>>>> Clearly this is the case if T is the set of reals and S the set of
>>>> integers.
>>> Clearly,  it is not because objects of the integer type do not have the
>>> division 'method' which its parent real  type has,  as simple as that,
>>> unless you deform the type of reals by excising division.
>> I don't think that is clear, at all, and in fact I think your argument
>> is actually circular. If we consider the two algebraic structures
>> (R,+,x,/, ..) and (Z,+,x, ..) and if we assume that Z is a subset of R
>> then there *is* a division operation for the elements in Z, namely the
>> one you find in the algebraic structure of R.

>
> So what is the result of 7/5 in Z remembering that a/b=c implies that
> a must be equal to b*c ?
>

>> Now your argument seems
>> to be based on the assumption that the sets R and Z are distinct,

>
> No, it's not based on that. Although, a typical construction of
> reals makes 2.0 and 2 quite distinct, we can pretend that they are the
> same ("up to the isomorphism"). The substantial point is that Z loses
> some properties after being 'subsetted' from R, e.g the division
> operation, which means in particular that one cannot substitute an
> integer(subtype) for a real(type) in any arbitrary expression as the
> LSP requires. One can derive various conclusions from that: integers
> are not a subtype of reals, the LSP definition is no good, the
> subtype as subset notion is no good, the OOP in its entirety is a
> bunch of baloney because it cannot even handle simple math structures
> ;), etc.
> ...

At the risk of being accused of misunderstanding some of what's been said in this thread (likely) and not having read all of it (true), I think you have just touched on something profound. From what I've seen, Darwen and Date and perhaps others have shown that it's possible to add operators and concepts to a strict version of the RM and achieve a kind of dynamic typing without the plumbing, eg., static linking, that many of today's programmers regard as arcane, cumbersome and somehow inefficient. The OOP people have shown that it's possible to create a great deal of confusion with a few simple concepts implemented in a myriad of ways.

In both cases, I think that just because something can be shown to be possible, eg., handle a few test cases apparently correctly, doesn't mean it should be done. Now, D&D are certainly smarter than I am, much more diligent and even if nobody implements what they have shown, they have still done yeoman work. Still, the bulk of the apps I've seen don't need that extended type support and the bulk of the commercial programmers I've seen couldn't master the concepts behind it. The same is more patent when it comes to oop. I'll grant that a few apps need more, but those deserve to be handled by people who are a little above-average. So as for most apps, what are we playing at?

My attitude is that once a critical mass in an engine is reached, it is silly to try to stretch it to encompass additional concepts. The reason it is silly is that no amount of manpower can validate it. My guess is that the critical mass I'm thinking of amounts to no more than several thousand lines of conventional low-level code. I wish more of the talent that worries about nulls and oop would spend more time trying to think of better low-level techniques for implementing and validating engines. There is a huge gap between the instruction sets and compilers of today's processors (which are basically unchanged from forty years ago and which so-called modern engines such as the jvm copy rather slavishly and which techniques haven't changed much either) and the theory (non-existent) to implement them on scales of tens of thousands, hundreds of thousands, or, as the big software vendors prove every day, millions of lines of engine code.

Just my two cents.

p

ps: my comment about jvm has nothing to do with the value of having an engine wherever there is a processor, IMHO that is the one thing Sun got right. Received on Mon Oct 16 2006 - 18:23:06 CDT