Re: Declarative constraints in practical terms

Marshall Spight wrote:
> 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.OK

Thanks. I knew I wasn't understanding that right.
>
> A simplistic example from Java would be use of the keyword
> "final" on a field. Do you know the pattern "value class"?

Yes.

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

OK.

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

What do you want in your language that you cannot get with Java?
>
> > > 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.

So if I'm using an x-terminal... scratch that, nevermind.

> In a 3-tier, it would be
> tier 3.

Tier 3 could be distributed, rather than centralized.

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

Would there be any reason to make the system of record for any code related to such data be something other than the system of record for the data? In other words, wouldn't you want to treat the constraints like the rest of the code, like the rest of the metadata? I can considering "user data" and "developer data" (metadata, code, constraints) with two different systems for maintenance and versioning.  That would be better than partitioning along the lines of "data + constraints" and "code," right?

> Clients
> pull constraints from the system of record in exactly the same
> way they pull data from the system of record.

And libraries/code?

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

Is it possible to have a language that implements the RM (including the Information Principle) and is a general purpose programming language?

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

But would not align with the Information Principle in its interface, although it could only persist data along the lines of the Information Principle (but then we are back to the current issues).

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

OK, so you would have relations as a data structure, that's fine. I have no problem with that. It is the IP that is problematic and also at the core of the RM, if I am understanding correctly. So, you are not implementing the RM, but relations, functions, sets... and related operations. I'm willing to play in that ballgame.

Cheers! --dawn Received on Mon Feb 27 2006 - 00:03:02 CET