Re: Storing data and code in a Db with LISP-like interface

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Tue, 2 May 2006 19:07:18 +0200
Message-ID: <13ryvaz4l99fz$.1me4dqxz3qbvb$.dlg@40tude.net>

On 2 May 2006 07:23:18 -0700, Marshall Spight wrote:

> Dmitry A. Kazakov wrote:

>> On Mon, 01 May 2006 21:36:58 GMT, Bob Badour wrote:
>>>
>>> That's interesting. What OO language supports basic set operations on
>>> object, classes or whatever? Where is the OO union? Intersect? Join?
>>> Cartesian product? What is the OO equivalent to project?
>>
>> 1. Objects
>>
>> There is no set operations on objects if they are not sets (=do not expose
>> public set interface) but it is easy to have such. A "Set" ADT is trivial
>> to design. Surely you wouldn't claim that numbers are not based on the set
>> theory, just because they don't have operation "intersect." Intersection of
>> two numbers is not a number. Same is true for most of types of objects.
>>
>> To be based on X /= implements X
>>
>> 2. Sets of objects
>>
>> Take any container library. They customary have sets, maps, bags of
>> objects. Note that sets of objects of different types is also possible.
>> These are class-wide containers (ones of polymorphic objects.)
>>
>> 3. Types
>>
>> This is more challenging and here set theoretical operations are supported
>> at full. To produce new types:
>>
>> 3.a. Union -> Multiple inheritance in virtual bases
>>
>> 3.b. Intersection -> Constrained subtypes, disallowing methods (the most
>> widely used case is T -> const T)
>>
>> 3.c. Join -> Inheritance with adding new methods. (Also much desired, but
>> rarely supported generalization by adding new values.) Lacks of types
>> system in this respect is often circumvented by adding abstract common
>> ancestors.
>>
>> 3.d. Cartesian product: Inheritance with extension (adding new members),
>> record types, multiple inheritance in methods.
>>
>> I am not sure what you meant under "project."
>>
>> 4. Classes
>>
>> A class is a closure of a set of types. Isn't it about sets?
>>
>> 5. Sets of types
>>
>> The generic programming is all about. Examples are templates and classes.
>>
>> -----------------
>> P.S. Carefully observe 3-5. This is what RM implementations usually lack
>> and why OO became more popular. Think about tables of tables and operations
>> defined on them. That would be an RM equivalent of generic programming.

> 
> This response, while carefully considered, is not compelling. It is
> almost entirely about the meta-level, not the data level.

Yes, because there is also a philosophic context. There is no data without or beyond operations defined on them. Individual numbers are of no interest. But the algebra of is.

> While points 1-2 are
> about the data level, it nonetheless shows that OOPLs *don't* support the
> relational algebra. The fact that you could code some up doesn't change
> that--that's a given. You can code anything up; that doesn't mean
> the language supports it. I want RA operators as primitives.

From my point of view anything that can be moved from the language core to the library level should be moved. We surely don't want set operations defined on numbers. The fact that numbers are constructed from sets in ZF changes nothing here.

A relational container library would be much welcome, but it is difficult to design because IMO modern types system are too weak. I don't see it as immanent to OOPL. A somewhat similar problem represents design of a good matrix library, with slices, submatrices, diagonals, symmetry, all carefully mapped to types. There are also things like dimensioned values. The point is that RM is only a fragment of a larger an more complex world. Or would you seriously propose to have a separate language for each? I don't buy all nGLs n>3. This includes not only SQL, but also UML, if that matters. (:-))

> Point 3 is telling. It shows how a number of meta-operations in OOPLs > are ad hoc restricted forms of relational operations.

Constrained, yes. The reason for this is not weakness of OO. The word "constraint" is important. Consider x**n + y**n = z**n. A trivial problem, if it weren't constrained to natural numbers. It is complex because it is. As a matter of fact, we do have constrained numbers, constrained types, constrained sets of types etc. This heavily influences the types algebra and, yes, opens a can of worms with program correctness.

A small side point. The way RM handles constraints is largely: "let's do it without and then look if something matches." This is inappropriate in numerous cases. Especially, when the set of solutions is large or even not countable. Or when solutions are very expensive to evaluate. Note also that the unconstrained space may even not exist. You cannot even copy all naturals from integers, because if you didn't created integers before. Think about program objects modeling uncountable, indiscrete, non-deterministic, uncertain things, their properties and relations.

> It was this realization,
> some years ago, that led me down the path of studying relational
> languages as a replacement for OOPLs. I would vastly prefer the
> clean and straightforwardness of the relational algebra (at the
> meta level) than the wonky inheritance rules of any OOPL.

For all, I don't see RA as a meta level. I don't see why the type of a column should be any better or worse than one of string or integer. To me all tables are values of one type. Your freedom and straightforwardness comes from simple fact that it is just one type, so far. FORTRAN-IV was also quite straightforward.

From other post:

> By way of expanding on that:

> Consider that almost everything fancy an OOPL can do
> can be accomplished with a small number of natual
> joins. But what is necessary to get an OOPL to do
> a natural join? I know of no programming language
> (outside of a few very new research languages,
> like perhaps Epigram) that can correctly assign
> a type to natural join. C++ can't do it. Haskell
> can't do it.

This is beside the point, because as I said before I agree with. Types systems are still underdeveloped. There is no even a commonly accepted formalism to describe and compare existing types systems. (Otherwise, there were no place for discussions like this.) But it is not an argument for having no or only predefined types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Received on Tue May 02 2006 - 12:07:18 CDT