Re: Homoiconic relational programming language

On Apr 9, 1:50 am, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
> On Apr 8, 3:12 pm, Nilone <rea..._at_gmail.com> wrote:
>
> > On Apr 8, 6:18 pm, Sampo Syreeni <de..._at_iki.fi> wrote:
>
> > > I've been thinking about this a lot, originally because of the dreaded
> > > "object-relational mismatch". What is it precisely that causes it?
>
> > I found a lot of value in the work of William Cook and Bart Jacobs,
> > the following papers in particular:
>
> > On understanding data abstraction, revisited (William R. Cook, 2009)
>
> Everybody on this group knows that among all other collections sets
> are special. Therefore the choice of a set for an object in W.Cook's
> latest paper is not very convincing. When comparing abstract data
> types and objects William interprets objects as characteristic
> function. OK, characteristic functions are defined on sets, this is
> why the choice of a set as an example is suspect. What is
> interpretation for other kinds of objects, e.g. free monoids (aka
> strings of characters), relations, etc? Or, maybe, objects always
> assume set structure so that instead of monoids we study semirings
> (sets of strings), relations as sets of tuples, and so on?

I doubt my mathematics background or understanding of those papers are sufficient to properly answer questions and objections about those papers. Still, I'll try to formulate a coherent reply.

What I got from those papers is that algebraic data types (arrays, tuples, relations) are structural abstractions, while Cook's procedural data abstractions, a.k.a. co-algebraic types, are behavioural abstractions and orthogonal to algebraic types.

If you view a value as an element of a closed domain, that's an algebraic view. Since the domain is closed, equality and other relations can be defined over the domain. Algebraic data structures allow us to derive and compose closed domains as well as the relations over those domains. In a closed, existential domain, elements have no behaviour, only value. It seems to me one of the themes of TTM is to properly describe the algebraic view.

Classes / PDAs / co-algebraic types define elements of an open domain via characteristic functions. Since the domain is open, equality and other relations can't be defined in general. Composition and derivation define behaviour, not value.

Modeling values as objects is inappropriate - since the domain is open and we only have a characteristic function by which to identify elements, it is always possible to define an imposter which breaks our assumptions. More than that, since we can't define the domain, relations over the domain are impossible and composition / derivation of new domains don't work as expected.

Similarly, modeling objects as values is inappropriate. The closed domain is always too restrictive, since we can't foresee all future behavioural requirements when we define it in the first place. In addition, it forces us to choose / deal with values that have no meaning, e.g. file handles, process ids, etc. Composition / derivation of new domains still don't work as expected, because it enforces relations over the domain that just don't apply.

That, in essence, is the object-relational mismatch from my current point of view. I hope I'm on the right track! Received on Fri Apr 09 2010 - 04:28:32 CEST