Re: Storing data and code in a Db with LISP-like interface
Date: Tue, 02 May 2006 18:06:16 GMT
Message-ID: <scN5g.2051$A26.59312_at_ursa-nb00s0.nbnet.nb.ca>
Dmitry A. Kazakov wrote:
> 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.
Do you understand the irony then when you point out structure without the set operations above?
>>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.
Are you suggesting this is a criticism of the RM? It isn't. Your focus on libraries reveals a profound disregard for the separation of concerns.
>>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.
If you believe a linear continuum is the same type as a four-dimensional continuum, your problems are much more fundamental than I first feared.
> 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.
Since nobody ever made that argument, I wonder why you would mention it? I suggest your behaviour reveals more about widespread ignorance and misconception in the industry than anything else. Received on Tue May 02 2006 - 20:06:16 CEST