Re: Declarative constraints in practical terms

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

Did you read the PDF yet? :-)

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

Sure. This is actually what I work on most days, a distributed tier 3. But despite the distribution, I still think of it as a single logical unit.

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

I don't see any reason offhand.

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

Yeah. I'm not into partitioning.

One thing to consider, though, is that client code doesn't necessarily stay in lock-sync with server code, and we have to be able to deal with that. If you're in the field and can just barely make a dialin link with your laptop, you don't want to have to download the newest 30 MB release of the email client; you just want to get you latests messages. You can get the new client when you get back to the office.

> > Clients
> > pull constraints from the system of record in exactly the same
> > way they pull data from the system of record.
>
> And libraries/code?

Ideally. But see above.

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

Sure. Take a simple relational language, with only relations, ints, strings, and set operations: union, intersection, projection, join. Add recursive functions. There you are! You have first class relational operations, and you also have a language that can compute any computable function.

Hitting that target is actually quite easy. Hitting that target and also having a good design is as hard as good design always is.

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

I think you and I have different ideas about the spirit of the Information Principle.

Me: "*all information* is represented by *data values* in relations." You: "all information is represented by data values in *relations*."

To my mind, if one does a good job of designing a system that integrates relations and lists, one could hold that system as adhering to the information principle:

"all information is represented by data values in relations or lists."

To me, the key spirit of the IP is that it focuses on values, (thus excludes pointers) and asserts that all information should be available in a uniform way. These are excellent points. Being conscious of the idea that all information should be available in a uniform way, I'm constantly pained by the fact that it's not. :-)

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

If the thing I'm working on ever sees the light of day, I think ... that you might like it.

Marshall Received on Mon Feb 27 2006 - 01:22:41 CET