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

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

> Dmitry A. Kazakov wrote:

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