Re: Declarative constraints in practical terms

Marshall Spight wrote:
> dawn wrote:
> >
> > Even if using a non-declarative programming language, one would
> > typically encode metadata (rules/constraints) so that the metadata
> > doesn't say how, but what.
>
> If that's so, then one is using declarative constraints.

Yes, and then coding using a general purpose language to validate based on the constraints.

> For example, if one is using a SQL engine that is written in
> C, an imperative language, ones constraints are still declarative.

Right.

> If one builds a declarative constraint enforcement/validation
> engine on top of one's application, one is using declarative
> constraints.

Yes. But might not be using a declarative language to test the constraints. That works for me.

> How powerful or complete the engine is doesn't affect whether
> it's declarative or not.

I understand that now. I was thinking of SQL when people talked about a declarative language, but I think I'm with the program now. The declarative language could be as simple as name=value pairs or as full-featured as a general purpose programming language.

> You could write a declarative engine
> whose only test it could make was whether one number was
> less than another number, and it'd still be declarative if a
> constraint looked like "a<b".

Got it.

> > A difference is whether a third-party
> > vendor is writing an engine that can typically handle more complex
> > specifications so that the declarations are more sophisticated than
> > name-value pairs (lookupTable=myCodes, type=String) and more
> > restrictive than a general purpose language.
>
> You don't explain this at all; I (and I expect many of us here) lack
> the background to understand what the name-value pairs are
> supposed to be.

I just mean metadata and values, such as an attribute named lookupTable with a value of "myCodes" (should have been MyCodes).

> > I'm still seeing pros and cons to each approach, but I do see
> > the perspective of why one might choose SQL constraints,
> > for example.
>
> I'm not sure whether you've done much programming in which
> you leaned on the static type system. One of the directions
> my programming style has moved to over the years is leaning
> more and more heavily on the type system, so-called "typeful
> programming." It's an amazingly powerful technique; you want
> to ensure certain properties of your programs; you declare
> these properties to the compiler; the compiler proves those
> properties, or doesn't allow you to proceed.
>
> It is true that Java gives one only very limited abilities to
> declare properties. One thing I've been wishing for for a
> while now is a programming language with a much more
> powerful way to declare static properties.

Java is the only OO language I have used. I have otherwise worked with more loosely typed environments. Do you mean static properties as "class variables" compared to instance variables or is there some other meaning?

> As an aside, earlier was mentioned the difference between
> data-management people and process people. (I forget the
> exact terms used.) Lately I no longer see a difference
> between data management and process; they are the same.

I very much agree with that. Data and process are two sides of the same coin. It is unwise to try to separate groups of developers into Proces & Data, for example.

> They have the same needs; they could even be made to
> use the identical type system. (In my system, relations and
> functions share a common generic type.)

Great! With my tools of choice, all data are persisted as functions anyway.

> What I would
> like is the ability to write declarative constraints in a
> strongly normalizing language (meaning that it always
> halts) and apply/enforce these constraints dynamically
> to data and statically to code.

I wish I really understood what that means. I'll work on it.

> Unfortunately first order predicate logic is not decidable,
> so there are still issues to be worked out. :-) This is why
> I'm looking at theorem provers right now; a lot of work
> has been done already in this area.
>
> > Whether the prescription is in one language (e.g. SQL) or another
> > (Java), it is still precise, right?
>
> Assuming the language involved allows no undefined or
> nondeterministic behavior. (But this is a minor point.)

agreed.
>
> > I do think I'm leaning a bit more in the direction of more
> > generic code where the totality of the rules are in metadata, but I'm
> > not yet leaning toward that being packaged with the dbms engine. Then
> > it is too hard to use the constraint specifications anywhere else.
>
> Yes, packaging is a separate issue. And we've had the
> constraint-portability discussion before; you and I both
> favored allowing constraints to migrate across tiers, although
> I'm not sure if you agreed with me that the system of record
> should be the central one.

I don't know if I agreed with that or not. What would "the central one" be?

> > So, my issues might be with SQL, a more restrictive language, used from
> > inside an RDBMS, forcing us to recode these same constraints in other
> > ways in other places.
>
> Yes, this is the portability issue again.

Both portability and a language that is not full-featured.

> But I think in this, and also in much wider contexts, your issue might
> be with SQL, and not declarative constraints or the RM or whatever
> else.

I worked for quite a while trying to determine if my issue was with SQL in particular or with the RM more generally. While there are more issues with SQL than the RM, I have a definite issue with the Informtion Principle, which is central, it seems, to the RM.

> For all its strengths, SQL has some significant deficiencies
> as a language. The abstraction facilities are virtually nonexistant,
> 3VL, no standard list support,

are you suggesting that the RM could provide list support in some other language and still be an implementation of the RM?

> tight coupling between schema and
> client code, etc. Consider how other languages from the 1970s
> look today. Substantially all of these deficiencies could be fixed
> with a new relational language, as has been suggested by others
> many times. :-)

I do not see how by definition a language could implement the RM and support list processing. Do you? --dawn Received on Sun Feb 26 2006 - 20:11:10 CET