Re: Declarative constraints in practical terms

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

Most of it, scanned the rest. It looks like they made the design-by-contract thing work with Java by adjusting the compiler, but I see that a language could be designed that way from the start.

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

If each database server has metadata in a different format (one is a SQL-DBMS and another is not, for example), it might make sense to have a separate business rules or metadata repository. This would also be advisable if the software is written to be database-independent so different customers can run it on different dbms platforms.

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

All code related to data is part of the system. If you are going to make changes to any component, you will want to know what else would need changing. Code is, in effect, metadata.

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

OK, but it could still be sourced with the rest of the system, even if the client only accepts a new copy when it wants to.

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

Hmmm. I wish I understood that better.

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

That is enlightening. You are right, that is how I hear it. Remove the requirement for all information to be represented by data values in relations and it doesn't quite seem like relational theory to me. If that is not a requirement, then I might have no beef with the RM.

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

It seems to me that you are no longer using relational theory, but relation & list theory.

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

And not violated by any approaches to dbms's today, right?

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

I sorta hate to say it, but the web and XML seem like the best shot to get that uniformity, don't you think?

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

Good deal. Cheers! --dawn Received on Sat Mar 04 2006 - 04:18:45 CET