Search found 76 matches
- Thu Nov 28, 2013 1:35 am
- Forum: Language Issues
- Topic: Yet another syntax query
- Replies: 4
- Views: 10846
Re: Yet another syntax query
Your suggestion is close to what I was trying to do. In fact my code will be based on: TYPE ID POSSREP {x CHAR}; VAR Domain BASE RELATION { domain ID, predicate CHARACTER } KEY { domain }; TYPE ident POSSREP {domain ID, name ID CONSTRAINT TUPLE { domain domain } IN Domain { domain } }; VAR Event BAS...
- Mon Nov 25, 2013 4:50 pm
- Forum: Language Issues
- Topic: Yet another syntax query
- Replies: 4
- Views: 10846
Re: Yet another syntax query
My second example shows what I am trying to do. A major component of my development is "domain" - an self contained area of interest in system development - eg application domain. It has nothing to do with the relational model use of the term domain. Every other item I define belongs to on...
- Fri Nov 22, 2013 8:53 pm
- Forum: Language Issues
- Topic: Yet another syntax query
- Replies: 4
- Views: 10846
Yet another syntax query
I have defined many lookup relvars which I use in defining types. For example: // Utillity type used throughout TYPE ID1 POSSREP { VALUE CHARACTER CONSTRAINT LENGTH ( VALUE ) <= 36 }; // Lookup relvar VAR lookup BASE RELATION { P ID1 } KEY { P }; // Lookup constrained type TYPE LU IS { ID1 CONSTRAIN...
- Wed Nov 20, 2013 6:34 pm
- Forum: Discussion
- Topic: A plug for Rel
- Replies: 1
- Views: 9088
Re: A plug for Rel
It would indeed be very nice.
- Sun Nov 17, 2013 11:19 pm
- Forum: Rel Examples
- Topic: Rationale for developing another type system.
- Replies: 3
- Views: 11590
Rationale for new base types
This system describes a set of data types, expressed in Rel. This type hierarchy is designed to support problem and requirements gathering and analysis. As such it needs to be able to represent types that may not have a computable representation, or which may be vague or ill-defined. The data types ...
- Fri Oct 25, 2013 5:58 pm
- Forum: Language Issues
- Topic: Specialisation by constraint
- Replies: 8
- Views: 14922
Re: Specialisation by constraint
Backup attached.
- Fri Oct 25, 2013 11:41 am
- Forum: Language Issues
- Topic: Specialisation by constraint
- Replies: 8
- Views: 14922
Re: Specialisation by constraint
Yes I do have more than one type inherited from integer - see my last post. I have one type inheriting directly from integer, with a subtype inheriting from that type; and one type defined without inheritance, but also with a subtype inheriting from it. In addition because I was exploring inheritanc...
- Fri Oct 25, 2013 11:33 am
- Forum: Language Issues
- Topic: Specialisation by constraint
- Replies: 8
- Views: 14922
Re: Specialisation by constraint
My aim in these examples was simply exploring the behaviour of types further, to assist me in writing operators. The examples were an attempt to do this exploration with the minimum of "clutter". What I was doing (I thought) was to define a type without inheritance Ntest1; and a type with ...
- Fri Oct 25, 2013 9:16 am
- Forum: Language Issues
- Topic: Specialisation by constraint
- Replies: 8
- Views: 14922
Re: Specialisation by constraint
In each case, where there are a pair of lines the first line is my input and the second the response. So
I entered Ntest2(9) and got the response Ntest2("[null-Ntest2-null]").Ntest2 ( 9 )
Ntest2("[null-Ntest2-null]")
- Thu Oct 24, 2013 11:01 am
- Forum: Language Issues
- Topic: Specialisation by constraint
- Replies: 8
- Views: 14922
Specialisation by constraint
After, I hope, learning a little about SbyC from the TTM mailing list, I used a variety of simple expressions to explore the behaviour of Rel in this respect. I have encountered a number of unexpected results and details are given below. INTEGER(10) 10 OP_PLUS ( 10, 10 ) 20 TYPE Ntest1 POSSREP { VAL...
- Sat Oct 19, 2013 3:56 pm
- Forum: Report a Bug
- Topic: Update oddty
- Replies: 3
- Views: 10510
Re: Update oddty
Is there then a way of storing a normal integer with a fixed number of significant places?
- Thu Oct 17, 2013 12:57 am
- Forum: Report a Bug
- Topic: Update oddty
- Replies: 3
- Views: 10510
Update oddty
The following are all valid tuples of Month_days_lookup: Month_days_lookup := RELATION { TUPLE { sort sort# ( 00 ), name ID ( "" ), days N31Z ( 0 ), prior_days N366Z ( 0 ) }, TUPLE { sort sort# ( 01 ), name ID ( "January" ), days N31Z ( 31 ), prior_days N366Z ( 0 ) }, TUPLE { sor...
- Sun Oct 13, 2013 3:27 pm
- Forum: Language Issues
- Topic: Expression evaluation syntax
- Replies: 4
- Views: 10374
Re: Expression evaluation syntax
Thank you for your suggestion. Also in the interval between asking the question and receiving your reply, I thin I can attack this in an alternative way - define unbounded_integer etc as a union data type.
- Sat Oct 12, 2013 6:23 pm
- Forum: Language Issues
- Topic: Expression evaluation syntax
- Replies: 4
- Views: 10374
Re: Expression evaluation syntax
Trying the first of your alternatives gives the error message: ERROR: java.lang.NumberFormatException: For input string: "unbounded" The relevant type definition is TYPE unbounded_integer POSSREP {VALUE CHAR CONSTRAINT (CAST_AS_INTEGER(VALUE) >= 0) OR (CAST_AS_INTEGER(VALUE) < 0) OR VALUE ...
- Fri Oct 11, 2013 10:13 pm
- Forum: Language Issues
- Topic: Expression evaluation syntax
- Replies: 4
- Views: 10374
Expression evaluation syntax
Is there a syntax to invoke an operator and obtain its value? My intended use of this is quick and dirty syntax testing while actually writing Rel code. The example I have is: If OPERATOR greater_than(P unbounded_integer, Q unbounded_integer) RETURNS BOOLEAN; CASE; WHEN Q = unbounded_integer("u...