The Rel Forum

Sorry--these problems appear to have been around since before you went to beta. It's taken me a while to get around to testing S-by-C support.

Having defined type ELLIPSE I tried this:

TYPE CIRCLE IS { ELLIPSE CONSTRAINT ( THE_A(ELLIPSE) = THE_B(ELLIPSE) ) } ;

It wasn't accepted, complaining that it found "}" when all sorts of other things were expected. Two comments:

1. Tutorial D allows the <derived possrep def list> to be empty.
2. Even if Rel decides to require it, shouldn't the keyword POSSREP be the only thing allowed after the paren that closes the constraint?

That said, I was pleased that

TYPE CIRCLE IS { ELLIPSE CONSTRAINT ( THE_A(ELLIPSE) = THE_B(ELLIPSE) ) POSSREP { R = THE_A(ELLIPSE) }} ;

worked fine. In this case a derived possrep is definitely desirable.

However, next I tried

TYPE posint IS { INTEGER CONSTRAINT ( INTEGER >= 0 ) } ;

and again Rel complained about the premature appearance of "}". But built-in type INTEGER surely has no explicit possrep, so how can I define a derived one (which in any case I really don't want)?

Hugh Darwen

Oops. This is a bug. It will be fixed in the next update.

As a temporary workaround, you can define a derivation of INTEGER as, for example: Parentheses are not required around the CONSTRAINT expression, so the parser expects the expression to continue in absence of the POSSREP keyword (or, what it should be, the '}') to end it, hence the all sorts of other things it could expect.

Sorry for a bad mistake in my bug report. It concerns this example:

TYPE CIRCLE IS { ELLIPSE CONSTRAINT ( THE_A(ELLIPSE) = THE_B(ELLIPSE) ) } ;

According to page 350 in Chapter 21 of our new book "Database Explorations", Rel is quite correct in rejecting this for lack of a <derived possrep def>. Chapter 21 is "Extending Tutorial D to Support the Inheritance Model".

However, the posint example is correct: a derived possrep is not needed if the immediate supertype is system-defined.

Regarding parens around the constraint expression, Dave is right: we don't require parens, so the closing paren in my example doesn't necessarily close the entire constraint. Sorry again.

I don't understand why "THE_VALUE(INTEGER)" is a legal expression in Rel if "INTEGER" on its own is not. In Chapter 21 we propose that a type name can be used in a specialization constraint to denote an arbitrary value of the type in question (which must be an immediate supertype of the type being defined by that constraint).

Hugh

HughDarwen wrote: I don't understand why "THE_VALUE(INTEGER)" is a legal expression in Rel if "INTEGER" on its own is not. In Chapter 21 we propose that a type name can be used in a specialization constraint to denote an arbitrary value of the type in question (which must be an immediate supertype of the type being defined by that constraint).

INTEGER denotes a type name, not a value, but THE_something(...) always returns a value so it was natural to use THE_VALUE(INTEGER). Also, THE_VALUE(INTEGER) emerged naturally from existing mechanisms, thus making it trivial to implement.

However, as per Chapter 21, I shall change Rel to allow "INTEGER" on its own.

Dave wrote:However, as per Chapter 21, I shall change Rel to allow "INTEGER" on its own.

I just realised, looking through the relevant Rel code, that I already implemented this several releases ago! I made an issue out of nothing. Mia culpa.