Subtype without additional possrep

This forum is to report technical problems with Rel.
Post Reply
HughDarwen
Posts: 121
Joined: Sat May 24, 2008 4:49 pm

Subtype without additional possrep

Post by HughDarwen »

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
Dave
Site Admin
Posts: 368
Joined: Sun Nov 27, 2005 7:19 pm

Re: Subtype without additional possrep

Post by Dave »

Oops. :roll: 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:

Code: Select all

TYPE posint IS {
  INTEGER CONSTRAINT THE_VALUE(INTEGER) >= 0
  POSSREP {a = THE_VALUE(INTEGER)}
};
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.
HughDarwen
Posts: 121
Joined: Sat May 24, 2008 4:49 pm

Re: Subtype without additional possrep

Post by HughDarwen »

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
Dave
Site Admin
Posts: 368
Joined: Sun Nov 27, 2005 7:19 pm

Re: Subtype without additional possrep

Post by Dave »

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
Site Admin
Posts: 368
Joined: Sun Nov 27, 2005 7:19 pm

Re: Subtype without additional possrep

Post by Dave »

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. :oops:
Post Reply