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

Dmitry A. Kazakov wrote:

> On Mon, 01 May 2006 21:36:58 GMT, Bob Badour wrote:
>

>>Dmitry A. Kazakov wrote:
>>
>>>On 1 May 2006 08:46:44 -0700, Marshall  Spight wrote:
>>>
>>>>Alvin  Ryder wrote:
>>>>
>>>>>Marshall  Spight wrote:
>>>>>
>>>>>>And anyway, I wouldn't say the RM is the best tool for
>>>>>>*everything.* Just the best tool for data management.
>>>>>
>>>>>Only certain kinds of data, it's not very good for: temporal, spatial,
>>>>>logic, oo, multimedia, unstructured and document libraries, ... but yes
>>>>>it has some strengths too.
>>>>
>>>>The RM is a practical application of set theory.
>>>
>>>The whole CS is. That includes OO (no matter what some proselytes would
>>>say.)
>>
>>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?

With all due respect, the type 'set' defines values and operations. Without the operations, the 'set' is pretty much useless.

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

Container libraries are for shit. Give me mathematics over some crappy physical implementation.

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

It's clear you did not understand what I meant by any of the above, either.

> 4. Classes
>
> A class is a closure of a set of types. Isn't it about sets?

So then, one should be able to define the set operations easily. Right? A join creates an entirely new type that is not a subtype of either of the things joined. A union creates something that strictly speaking defines a superset of the values of the types joined, which would mean it could define a supertype of the things joined but not a subtype of either. Cartesian product creates a new type that is neither a supertype nor a subtype of either of its operands.

Your replies in 3 to support your assertion that set operations are supported actually contradicts the assertion.

A supertype is a superset of values and a subset of operations. However, this observation hardly leverages the power of set algebra and the equivalent predicate logic. Now does it?

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

Actually, 3-5 demonstrate the ignorance in the industry. Conflating concerns is stupid as is an exclusive focus on structure without regard to operations or to manipulation.

  Think about tables of tables and operations
> defined on them. That would be an RM equivalent of generic programming.

Yes, it would. However, you have failed to establish that OO is an application of set theory. At best, you have suggested one can use sets to describe the ad hoc shit the OO disciples promote. Received on Tue May 02 2006 - 19:58:44 CEST