Google Summer of Code

[Robin Green]

On Fri, Jun 10, 2005 at 07:25:38PM +0200, Massimo Dentico wrote:
> >> If it is sufficient general then this
> >> protocol is no more powerful than the Relational Algebra or the 
> >Tuple/Domain
> >> Calculi (this is not exactly true, RA is not Turing-equivalent on 
> >purpose).
> >
> >That is a crucial difference. Therefore it _is_ more powerful.
> 
> You don't know what you are speaking about: RA is not Turing-equivalent
> to avoid not terminating operations (infinite loops), because end-users
> and application programmers can formulate arbitrary queries and too much
> power in this case is dangerous.

Actually, I do know what I am talking about. You said it was not more powerful.
In fact, it is more powerful, in useful ways.

> If you properly specify pre/post conditions

Which I did.

> and invariants the difference
> lay in values/pointers semantics.

No it doesn't. I already proved otherwise: that you can have Sets which aren't
Bags in both, and you can have Sets which *are* Bags in both, depending on how
you define a bag.

What you are seeing is, you are choosing different subtly *different*
pre/post-conditions for your "pointers" case and your "values" case, and then
declaring that the difference is due to "pointers". It isn't. It's due to your
subtly different pre/post-conditions.

> A Set is a special case of a Bag

But is it? I cannot add the same value twice to a Set and expect it to
grow in size by 2, but I can with an ordinary Bag.

> If you give up with pointer semantics (or no object identity, no aliasing;
> there are subtle differences, see the paper about Kaleidoscope below)
> there are no problems with subtyping and supertyping (subsets and 
> supersets).

Yes there are. I've just told you what the problem is. It doesn't have anything
to do with pointers, or aliasing, or object identity, or even objects per se. It
has to do with behavioural subtyping. Did you read my post?

> On this and LSP, see "WHAT DOES SUBSTITUTABILITY REALLY MEAN?":
> 
> Part 1: http://www.dbdebunk.com/page/page/626998.htm
> Part 2: http://www.dbdebunk.com/page/page/626996.htm
> Part 3: http://www.dbdebunk.com/page/page/626987.htm
> Part 4: http://www.dbdebunk.com/page/page/626958.htm
> Part 5: http://www.dbdebunk.com/page/page/622357.htm
> Part 6: http://www.dbdebunk.com/page/page/622347.htm

Ouch. I much prefer *writing* excrutiating pedantry, to *reading* it. ;-)

Date is right that some of the literature is somewhat sloppy and confused.
I'll grant you that.

However, his model is flawed. He says: "What we definitely wouldn't do,
however, is have two distinct versions of the same method, a subtype version
and a supertype version, both explicitly user-visible, with two distinct sets
of preconditions and postconditions."

His model therefore does not allow for polymorphism-of-contracts (where the
contract varies depending on which subtype an object is, while still adhering
to LSP). I don't understand why he thinks behavioural variations between
supertypes and subtypes should be necessarily and always hidden. Vegan
restaurants are restaurants, but when I visit them and order a meal, I'm
very interested in the fact that the behaviour of the staff will
differ from that of a normal restaurant - they won't offer me anything that
isn't vegan!

<snip>

> >> Do you understand that you are constructing, with your "librify it",
> >> "what is the problem", a DBMS, bit by bit?
> >
> >Yes. An OODBMS, which I prefer to an RDBMS.
> 
> Done in the past. Failed.

I think the companies which are basing successful businesses on OODBMSs
(or at least, things which look to the user every bit like OODBMSs, even if
they use an RDBMS "under the hood"), would beg to differ with you there.

> >Eventually, they will not merely "error out" on constraints violations
> >like RDBMSs can, but they will actually model-check a program to prove
> >that it is incapable of violating any integrity constraints. (That's my
> >main research interest.) Beat that!
> 
> I don't need to beat anything. You cannot statically check something
> that does not exist yet: an arbitrarly constraint can check values of
> one time-varying table (relvar) aginst the values of another time-varying
> table or you need to check constraints when a user arbitrarly manipulate
> data.

That's true. However, my point was that OO languages would one day surpass
the abilities of RDBMSs to prevent constraint violations.

> Very *ironically* researchers in program analysis and model checking
> are realizing that a Relational Algebra interface to their tools (BDDs
> to be specific) simplifies things greatly, see point 4. under the
> section "Now, the evidence" here:
> 
>    http://cliki.tunes.org/KnowOS

Very interesting.
-- 
Robin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /archives/tunes/attachments/20050610/411dfcce/attachment.bin