Re: Declarative constraints in practical terms

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.

For example, if one is using a SQL engine that is written in C, an imperative language, ones constraints are still declarative. If one builds a declarative constraint enforcement/validation engine on top of one's application, one is using declarative constraints.

How powerful or complete the engine is doesn't affect whether it's declarative or not. 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".

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

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

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

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

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

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. For all its strengths, SQL has some significant deficiencies as a language. The abstraction facilities are virtually nonexistant, 3VL, no standard list support, 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. :-)  

Marshall Received on Sun Feb 26 2006 - 18:00:44 CET