Re: a high level language

From: Patrick Dowler <patrick.dowler-at-nrc-cnrc.gc.ca>
Date: Thu, 27 Feb 2003 16:32:24 -0800


On February 24, 2003 13:56, Tony Linde wrote:
> Hi Patrick,
>
> > Our work at CADC and some of my past work has been in the
> > area of constraint systems.
>
> Do you have some refs?

Sorry to be tardy in replying - I was home sick for a couple of days :-(

I don't have any good reference material for the constraint package that we have developed, but it is simple enough that I'll include something right here.

I should note that this way of doing it has the added advantage of separating the query language and the meta-data (which is "content" in the constraint system).

We have a java package (toolkit) which can be used to construct constraints. A set of constraints forms a query - not counting the specification of output format, which we handle separately. More exactly, a constraint set specifies a "set of things" namely the things which satisfy the constraints. How one views the set of things (ie. the output of the query) is a separate issue.

So, out package has the following classes (I show the constructor for each because that shows how they relate and are built). Indentation shows class hierarchy.

Expression

       Constant(String | Number | ??)
       Property(String)
       Operator
              Add(Expression, Expression)
              Sub(Expression, Expression)
              Mul(Expression, Expression)
              Div(Expression, Expression)
              Size(...)
              Area(...)
              etc...

Constraint
      Known(Property)             cruft: arg should be an Expression
      Unknown(Property)          cruft: arg should be an Expression
      Eq(Expression,Expression)
      Leq(Expression,Expression)
      Geq(Expression,Expression)
      Between(Expression,Expression,Expression)
      Contains(Property.Interval, Number)     cruft: 2nd arg should be type-safe Constant
      Intersect(Property.Shape, Shape)        cruft: 2nd arg should be type-safe Constant

Note: Property.Interval and Property.Shape are subclasses of Property that let one enforce some type safety in constraint construction... we're currently rather ambivalent about compile-time vs. runtime type checking (experimental stage :-)

Other note: any mention of a Property in any Expression implies a Known constraint for that that Property. Known is just a way of saying "I want to see it or include it, but I don't care about the value".

Where does the meta-data fit in? It is the content of the Property objects.

What about boolean operators? In a constraint-based system, a set of constraints are implicitly AND. One could easily implement an OR as a Constraint type:

    Or(Constraint, Constraint)

How does this relate to other VO stuff? The types of values (as used in Constant or Property objects) are at the base of both the constraint system and the data model. For example, if you want to have polygons in a data model, you need polygon-compatible Property and Constant objects in the constraint system and you need Constraint types that know deal with those types.

Why is it soooooo OO? Anyone whose written a parser will recognize the above classes as the nodes of a parse tree. We came to the realisation that all over our systems we had to deal with parse trees: the query generators convert a parse tree to SQL, the UI creates a parse tree from UI elements, etc. So the natural choice for a model of the query is a constraint system (parse tree). Then we can operate solely in the domain of the constraints throughout most of our software.

Examples:

     x <= 2
     y + 1 > 5
     z is known

becomes:

    new Leq( new Property("x"), new Constant(2) )     new Geq( new Operator.add( new Property("y"), new Constant(1) ), new Constant(5) )     new Known( new Property("z") )

Note that the "cone search" service can be expressed as:

    new Intersect( new Property("position_equ"), new Circle2D(ra, dec, radius) )

Of course, it is trivial to serialise a parse tree in a tree-oriented text format ike XML, and the first thing the software at the other end will do is convert the XML document back into a tree (data structure) again.

Anyway, we have a Java package that does this, but it is closely tied with our data model package (really it is a "types" package of things missing from or done incorrectly in java2). It wouldn't be too hard to implement this in other languages, but I'm more throwing it out there as a way to do a QL that isn't a "language" because I think that way leads to lots of complication and pain.

If anyone has more interest in this stuff, let me know.

-- 
Patrick Dowler
Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045
Canadian Astronomy Data Centre    | Centre canadien de donnees astronomiques
National Research Council Canada  | Conseil national de recherches Canada
Government of Canada                   | Gouvernement du Canada
5071 West Saanich Road                | 5071, chemin West Saanich
Victoria, BC                                   | Victoria (C.-B.)
Received on 2003-02-28Z01:34:15