Re: Declarative constraints in practical terms

dawn wrote:
> > 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?

Some other meaning. In this case, I mean roughly compile-time properties. That is, properties that are *always* true of the program, as opposed to properties that are true of a particular run, or at a particular moment.

A simplistic example from Java would be use of the keyword "final" on a field. Do you know the pattern "value class"? In essence, this describes a class that cannot be modified once it is constructed. String and Integer are examples of value classes. The unmodifiable property is required to use a class as a key in a Map. (aka Hashtable.)

One choice for implementing a value class would be, just don't assign to any of the instance fields. You can verify this property by checking every line in the class to see whether it assigns to any instance fields. Alternatively, you could *declare* (there's that word :-) all the fields to be final. Using that technique, you can verify that a class has the unmodifiability property by inspecting *only* the field declarations.

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

Check out JML.
http://www.cs.iastate.edu/~leavens/JML/

This paper makes interesting reading about JML. ftp://ftp.cs.iastate.edu/pub/leavens/JML/jmldbc.pdf

This is all done in a Java context, and I'm moving in a different direction, but the principles are much the same.

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

In a client/server, it would be the server. In a 3-tier, it would be tier 3. In a multiclient-single server setup, it would be the server. Etc. Whenever you have data, it makes sense to identify the system of record. I propose the system of record for the data should be the system of record for the constraints. Clients pull constraints from the system of record in exactly the same way they pull data from the system of record.

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

There is no requirement that the language not be full-featured, although if one uses a turing complete language to enforce constraints, one has to contend with the fact that a constraint check (or validity check) may go in to an infinite loop.

> I do not see how by definition a language could implement the RM and
> support list processing. Do you?

They are not mutually exclusive. One could take the design choice of having all top-level entities be lists of relations. Or relations of lists. I have played with both of those ideas, and they each have some merit. But my current thinking is just to include both.

The language would then by definition not be exclusively-relational or purely-relational. But it would still be relational.

In comparison, people still call SML a functional language, but they don't call it a purely-functional language, because it includes some imperative features. But the emphasis is still on the functional.

Marshall Received on Sun Feb 26 2006 - 22:56:22 CET