Home » Modeling » OCL » VariableCS.initExpr = null when parsing a Tuplizing query
| VariableCS.initExpr = null when parsing a Tuplizing query [message #68945] |
Mon, 16 March 2009 13:23  |
Eclipse User |
|
|
|
Hello,
I'm somewhat of an OCL MDT novice, so please bear with me! I'm
attempting to write my first queries which return tuplized results.
First off, I can't seem to find any documentation on the proper way to
write these queries and have taken all of my guidance from the example
in the 'MDT OCL Goes Generic' eclipsecon presentation. Is there a more
elaborate primer on this topic?
My first observation is that I get a parse exception if I initialize the
Tuple with parentheses, it appears to want brackets (so Tuple{x : T, x2
:T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
My current problem is that I'm getting a NullPointer that appears to
boil down to my specification of the Tuple fields. The following is a
simplified query that is not parsing:
String queryString = "Set(Tuple{task : Task}) = " +
"let overrun : Set(Task) = " +
"self.tasks->select(t : Task | " +
"t.blownTask<>null) in " +
"overrun->collect(t | Tuple{" +
"task = t})";
The full query I'm trying to write is tuplizing three fields, but I've
tried to cut this one down as much as I can. As I said, I get a
NullPointer when parsing this query, and when I unwind the stack trace
in debug mode, the trouble seems to start at line 2855 of
AbstractOCLAnalyzer (src.zip for build 1.2.3).
At that point in the code, the parser is building instances of
TupleLiteralPart for each of the declared tuple fields. Each has three
parts - name, type and expr. In the debug console, 'name' is assigned
correctly ("task"), and so is 'type' (EClass for 'Task'), but 'expr' is
null because the object we're building from (an instance of VariableCS)
returns 'null' for getInitExpression().
So what am I doing wrong? Is there something else I am supposed to be
doing is the query to make sure that 'task' is initialized? Since it is
being assigned in the 'collect' clause, what would be the point?
Thank you for your assistance,
Daniel
|
|
|
| Re: VariableCS.initExpr = null when parsing a Tuplizing query [message #68990 is a reply to message #68945] |
Thu, 19 March 2009 08:52  |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
--=-24Ww0e0kYvaRNrW2HhbI
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Daniel,
See some replies in-line, below.
HTH,
Christian
On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
> Hello,
>
> I'm somewhat of an OCL MDT novice, so please bear with me! I'm
> attempting to write my first queries which return tuplized results.
> First off, I can't seem to find any documentation on the proper way to
> write these queries and have taken all of my guidance from the example
> in the 'MDT OCL Goes Generic' eclipsecon presentation. Is there a more
> elaborate primer on this topic?
Do you mean, besides the OCL Specification? You might try the
introductory materials in the Open Model CourseWare project (OMCW) here
at Eclipse.
> My first observation is that I get a parse exception if I initialize the
> Tuple with parentheses, it appears to want brackets (so Tuple{x : T, x2
> :T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
The parentheses are used in the identification of a tuple *type* just as
for collection types, e.g., Set(Employee) . The braces are used to
construct a tuple value just as for collections, e.g., Set{self,
self.manager} .
> My current problem is that I'm getting a NullPointer that appears to
> boil down to my specification of the Tuple fields. The following is a
> simplified query that is not parsing:
>
> String queryString = "Set(Tuple{task : Task}) = " +
> "let overrun : Set(Task) = " +
> "self.tasks->select(t : Task | " +
> "t.blownTask<>null) in " +
> "overrun->collect(t | Tuple{" +
> "task = t})";
That should be:
String queryString = "Set(Tuple(task : Task)) = " +
"let overrun : Set(Task) = " +
"self.tasks->select(t : Task | " +
"t.blownTask<>null) in " +
"overrun->collect(t | Tuple{t})";
So, use parentheses in the tuple type reference and just fill in the
tuple parts in the literal expression. The tuple parts are ordered, so
the inferred type of the tuple literal in the collect expression is the
same type as declared in the element type of the set type. At least, I
think that should work ...
> The full query I'm trying to write is tuplizing three fields, but I've
> tried to cut this one down as much as I can. As I said, I get a
> NullPointer when parsing this query, and when I unwind the stack trace
> in debug mode, the trouble seems to start at line 2855 of
> AbstractOCLAnalyzer (src.zip for build 1.2.3).
>
> At that point in the code, the parser is building instances of
> TupleLiteralPart for each of the declared tuple fields. Each has three
> parts - name, type and expr. In the debug console, 'name' is assigned
> correctly ("task"), and so is 'type' (EClass for 'Task'), but 'expr' is
> null because the object we're building from (an instance of VariableCS)
> returns 'null' for getInitExpression().
I suspect that what is happening, here, is that the parser is actually
processing the misplaced tuple literal in the Set type reference? Tuple
parts can have null values, and the 't' variable should be well-formed.
> So what am I doing wrong? Is there something else I am supposed to be
> doing is the query to make sure that 'task' is initialized? Since it is
> being assigned in the 'collect' clause, what would be the point?
I suspect that it all stems from the parser getting confused by the
misplaced tuple literal in your set type, instead of a tuple type.
>
> Thank you for your assistance,
>
> Daniel
--=-24Ww0e0kYvaRNrW2HhbI
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Daniel,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hello,
I'm somewhat of an OCL MDT novice, so please bear with me! I'm
attempting to write my first queries which return tuplized results.
First off, I can't seem to find any documentation on the proper way to
write these queries and have taken all of my guidance from the example
in the 'MDT OCL Goes Generic' eclipsecon presentation. Is there a more
elaborate primer on this topic?
</PRE>
</BLOCKQUOTE>
<BR>
Do you mean, besides the OCL Specification? You might try the introductory materials in the Open Model CourseWare project (OMCW) here at Eclipse.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
My first observation is that I get a parse exception if I initialize the
Tuple with parentheses, it appears to want brackets (so Tuple{x : T, x2
:T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
</PRE>
</BLOCKQUOTE>
<BR>
The parentheses are used in the identification of a tuple *type* just as for collection types, e.g., Set(Employee) . The braces are used to construct a tuple value just as for collections, e.g., Set{self, self.manager} .<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
My current problem is that I'm getting a NullPointer that appears to
boil down to my specification of the Tuple fields. The following is a
simplified query that is not parsing:
String queryString = "Set(Tuple{task : Task}) = " +
"let overrun : Set(Task) = " +
"self.tasks->select(t : Task | " +
"t.blownTask<>null) in " +
"overrun->collect(t | Tuple{" +
"task = t})";
</PRE>
</BLOCKQUOTE>
<BR>
That should be:<BR>
<BR>
String queryString = "Set(Tuple(task : Task)) = " +<BR>
"let overrun : Set(Task) = " +<BR>
"self.tasks->select(t : Task | " +<BR>
"t.blownTask<>null) in " +<BR>
"overrun->collect(t | Tuple{t})";<BR>
<BR>
So, use parentheses in the tuple type reference and just fill in the tuple parts in the literal expression. The tuple parts are ordered, so the inferred type of the tuple literal in the collect expression is the same type as declared in the element type of the set type. At least, I think that should work ...<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
The full query I'm trying to write is tuplizing three fields, but I've
tried to cut this one down as much as I can. As I said, I get a
NullPointer when parsing this query, and when I unwind the stack trace
in debug mode, the trouble seems to start at line 2855 of
AbstractOCLAnalyzer (src.zip for build 1.2.3).
At that point in the code, the parser is building instances of
TupleLiteralPart for each of the declared tuple fields. Each has three
parts - name, type and expr. In the debug console, 'name' is assigned
correctly ("task"), and so is 'type' (EClass for 'Task'), but 'expr' is
null because the object we're building from (an instance of VariableCS)
returns 'null' for getInitExpression().
</PRE>
</BLOCKQUOTE>
<BR>
I suspect that what is happening, here, is that the parser is actually processing the misplaced tuple literal in the Set type reference? Tuple parts can have null values, and the 't' variable should be well-formed.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
So what am I doing wrong? Is there something else I am supposed to be
doing is the query to make sure that 'task' is initialized? Since it is
being assigned in the 'collect' clause, what would be the point?
</PRE>
</BLOCKQUOTE>
<BR>
I suspect that it all stems from the parser getting confused by the misplaced tuple literal in your set type, instead of a tuple type.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Thank you for your assistance,
Daniel
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-24Ww0e0kYvaRNrW2HhbI--
|
|
|
| Re: VariableCS.initExpr = null when parsing a Tuplizing query [message #69014 is a reply to message #68990] |
Thu, 19 March 2009 14:28 |
| Eclipse User |
|
|
|
Christian,
Thanks for your comments. Alas, I still can't seem to get a handle on
the exact syntax. The real break may be getting a simple example of a
well-formed query which returns a set of tuples, and then working from
there.
In thorough examination of both the OCL spec and your comments, I would
think that the following is well-formed:
String queryStr = "let tuplized : Set(Tuple(task : Task)) =
self.tasks->collect(t | Tuple{t}) in tuplized->asSet()"
Parsing this query generates a similar parse exception as described
previously (a NullPointer at OCLFactoryImpl:153 - when processing the
tuple specification).
However, my interpretation of the OCL Spec is that the correct syntax
would use the 'TupleType' keyword instead of the first occurrence of
'Tuple' in the above query. The parser seems to have other ideas,
returning org.eclipse.ocl.SyntaxException: 1:20:1:28 "Tuple" expected
instead of "TupleType".
What is the simplest query in EMF OCL that will return me a set of tuples?
Thanks,
Daniel
Christian W. Damus wrote:
> Hi, Daniel,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
> On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
>> Hello,
>>
>> I'm somewhat of an OCL MDT novice, so please bear with me! I'm
>> attempting to write my first queries which return tuplized results.
>> First off, I can't seem to find any documentation on the proper way to
>> write these queries and have taken all of my guidance from the example
>> in the 'MDT OCL Goes Generic' eclipsecon presentation. Is there a more
>> elaborate primer on this topic?
>
> Do you mean, besides the OCL Specification? You might try the
> introductory materials in the Open Model CourseWare project (OMCW) here
> at Eclipse.
>
>
>> My first observation is that I get a parse exception if I initialize the
>> Tuple with parentheses, it appears to want brackets (so Tuple{x : T, x2
>> :T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
>
> The parentheses are used in the identification of a tuple *type* just as
> for collection types, e.g., Set(Employee) . The braces are used to
> construct a tuple value just as for collections, e.g., Set{self,
> self.manager} .
>
>
>> My current problem is that I'm getting a NullPointer that appears to
>> boil down to my specification of the Tuple fields. The following is a
>> simplified query that is not parsing:
>>
>> String queryString = "Set(Tuple{task : Task}) = " +
>> "let overrun : Set(Task) = " +
>> "self.tasks->select(t : Task | " +
>> "t.blownTask<>null) in " +
>> "overrun->collect(t | Tuple{" +
>> "task = t})";
>
> That should be:
>
> String queryString = "Set(Tuple(task : Task)) = " +
> "let overrun : Set(Task) = " +
> "self.tasks->select(t : Task | " +
> "t.blownTask<>null) in " +
> "overrun->collect(t | Tuple{t})";
>
> So, use parentheses in the tuple type reference and just fill in the
> tuple parts in the literal expression. The tuple parts are ordered, so
> the inferred type of the tuple literal in the collect expression is the
> same type as declared in the element type of the set type. At least, I
> think that should work ...
>
>> The full query I'm trying to write is tuplizing three fields, but I've
>> tried to cut this one down as much as I can. As I said, I get a
>> NullPointer when parsing this query, and when I unwind the stack trace
>> in debug mode, the trouble seems to start at line 2855 of
>> AbstractOCLAnalyzer (src.zip for build 1.2.3).
>>
>> At that point in the code, the parser is building instances of
>> TupleLiteralPart for each of the declared tuple fields. Each has three
>> parts - name, type and expr. In the debug console, 'name' is assigned
>> correctly ("task"), and so is 'type' (EClass for 'Task'), but 'expr' is
>> null because the object we're building from (an instance of VariableCS)
>> returns 'null' for getInitExpression().
>
> I suspect that what is happening, here, is that the parser is actually
> processing the misplaced tuple literal in the Set type reference? Tuple
> parts can have null values, and the 't' variable should be well-formed.
>
>> So what am I doing wrong? Is there something else I am supposed to be
>> doing is the query to make sure that 'task' is initialized? Since it is
>> being assigned in the 'collect' clause, what would be the point?
>
> I suspect that it all stems from the parser getting confused by the
> misplaced tuple literal in your set type, instead of a tuple type.
>
>>
>> Thank you for your assistance,
>>
>> Daniel
|
|
|
| Re: VariableCS.initExpr = null when parsing a Tuplizing query [message #69056 is a reply to message #69014] |
Thu, 19 March 2009 15:37 |
| Eclipse User |
|
|
|
Christian,
I may have stumbled across the error. I'm posting the solution in case
it is useful to other readers, and because I am curious for you to
verify the rationale.
The query works if I add another field to the tuple, as in:
String queryString = "let tuplized : Set(Tuple(task : Task, cost :
Integer)) = self.tasks->collect(t | Tuple{cost = t.cost, task =
t})->asSet() in tuplized->asSet()";
I'm inclined to think that tuples are not well-formed unless they
specify at least 2 component parts, and that the parser just isn't
equipped to express that in an exception. Is that correct?
Thanks,
Daniel
Daniel Tuohy wrote:
> Christian,
>
> Thanks for your comments. Alas, I still can't seem to get a handle on
> the exact syntax. The real break may be getting a simple example of a
> well-formed query which returns a set of tuples, and then working from
> there.
>
> In thorough examination of both the OCL spec and your comments, I would
> think that the following is well-formed:
>
> String queryStr = "let tuplized : Set(Tuple(task : Task)) =
> self.tasks->collect(t | Tuple{t}) in tuplized->asSet()"
>
> Parsing this query generates a similar parse exception as described
> previously (a NullPointer at OCLFactoryImpl:153 - when processing the
> tuple specification).
>
> However, my interpretation of the OCL Spec is that the correct syntax
> would use the 'TupleType' keyword instead of the first occurrence of
> 'Tuple' in the above query. The parser seems to have other ideas,
> returning org.eclipse.ocl.SyntaxException: 1:20:1:28 "Tuple" expected
> instead of "TupleType".
>
> What is the simplest query in EMF OCL that will return me a set of tuples?
>
> Thanks,
> Daniel
>
> Christian W. Damus wrote:
>> Hi, Daniel,
>>
>> See some replies in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>> On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
>>> Hello,
>>>
>>> I'm somewhat of an OCL MDT novice, so please bear with me! I'm
>>> attempting to write my first queries which return tuplized results.
>>> First off, I can't seem to find any documentation on the proper way
>>> to write these queries and have taken all of my guidance from the
>>> example in the 'MDT OCL Goes Generic' eclipsecon presentation. Is
>>> there a more elaborate primer on this topic?
>>
>> Do you mean, besides the OCL Specification? You might try the
>> introductory materials in the Open Model CourseWare project (OMCW)
>> here at Eclipse.
>>
>>
>>> My first observation is that I get a parse exception if I initialize
>>> the Tuple with parentheses, it appears to want brackets (so Tuple{x :
>>> T, x2 :T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
>>
>> The parentheses are used in the identification of a tuple *type* just
>> as for collection types, e.g., Set(Employee) . The braces are used to
>> construct a tuple value just as for collections, e.g., Set{self,
>> self.manager} .
>>
>>
>>> My current problem is that I'm getting a NullPointer that appears to
>>> boil down to my specification of the Tuple fields. The following is
>>> a simplified query that is not parsing:
>>>
>>> String queryString = "Set(Tuple{task : Task}) = " +
>>> "let overrun : Set(Task) = " +
>>> "self.tasks->select(t : Task | " +
>>> "t.blownTask<>null) in " +
>>> "overrun->collect(t | Tuple{" +
>>> "task = t})";
>>
>> That should be:
>>
>> String queryString = "Set(Tuple(task : Task)) = " +
>> "let overrun : Set(Task) = " +
>> "self.tasks->select(t : Task | " +
>> "t.blownTask<>null) in " +
>> "overrun->collect(t | Tuple{t})";
>>
>> So, use parentheses in the tuple type reference and just fill in the
>> tuple parts in the literal expression. The tuple parts are ordered,
>> so the inferred type of the tuple literal in the collect expression is
>> the same type as declared in the element type of the set type. At
>> least, I think that should work ...
>>
>>> The full query I'm trying to write is tuplizing three fields, but
>>> I've tried to cut this one down as much as I can. As I said, I get a
>>> NullPointer when parsing this query, and when I unwind the stack
>>> trace in debug mode, the trouble seems to start at line 2855 of
>>> AbstractOCLAnalyzer (src.zip for build 1.2.3).
>>>
>>> At that point in the code, the parser is building instances of
>>> TupleLiteralPart for each of the declared tuple fields. Each has
>>> three parts - name, type and expr. In the debug console, 'name' is
>>> assigned correctly ("task"), and so is 'type' (EClass for 'Task'),
>>> but 'expr' is null because the object we're building from (an
>>> instance of VariableCS) returns 'null' for getInitExpression().
>>
>> I suspect that what is happening, here, is that the parser is actually
>> processing the misplaced tuple literal in the Set type reference?
>> Tuple parts can have null values, and the 't' variable should be
>> well-formed.
>>
>>> So what am I doing wrong? Is there something else I am supposed to
>>> be doing is the query to make sure that 'task' is initialized? Since
>>> it is being assigned in the 'collect' clause, what would be the point?
>>
>> I suspect that it all stems from the parser getting confused by the
>> misplaced tuple literal in your set type, instead of a tuple type.
>>
>>>
>>> Thank you for your assistance,
>>>
>>> Daniel
|
|
|
| Re: VariableCS.initExpr = null when parsing a Tuplizing query [message #69078 is a reply to message #69056] |
Thu, 19 March 2009 16:00 |
| Eclipse User |
|
|
|
Hi again!
The problem is not that a tuple requires multiple components. My
current guess is that a Tuple must have at least one component that is a
primitive. My reason for suggesting this is:
- Tuple(x : Foo, y : Bar, z : Baz, p : Integer)
- Tuple(x : Foo, y : Bar, z : Baz, p : String)
- Tuple(p : String)
- Tuple(p : Integer)
....all parse correctly, however:
- Tuple(x : Foo, y : Bar, z : Baz)
- Tuple(x : Foo)
....cause a NullPointerException in the parser when processing the
variable specs.
It seems awfully silly, but is it possible that Tuples require a
primitive component?
Thanks,
Daniel
Daniel Tuohy wrote:
> Christian,
>
> I may have stumbled across the error. I'm posting the solution in case
> it is useful to other readers, and because I am curious for you to
> verify the rationale.
>
> The query works if I add another field to the tuple, as in:
>
> String queryString = "let tuplized : Set(Tuple(task : Task, cost :
> Integer)) = self.tasks->collect(t | Tuple{cost = t.cost, task =
> t})->asSet() in tuplized->asSet()";
>
> I'm inclined to think that tuples are not well-formed unless they
> specify at least 2 component parts, and that the parser just isn't
> equipped to express that in an exception. Is that correct?
>
> Thanks,
> Daniel
>
> Daniel Tuohy wrote:
>> Christian,
>>
>> Thanks for your comments. Alas, I still can't seem to get a handle on
>> the exact syntax. The real break may be getting a simple example of a
>> well-formed query which returns a set of tuples, and then working from
>> there.
>>
>> In thorough examination of both the OCL spec and your comments, I
>> would think that the following is well-formed:
>>
>> String queryStr = "let tuplized : Set(Tuple(task : Task)) =
>> self.tasks->collect(t | Tuple{t}) in tuplized->asSet()"
>>
>> Parsing this query generates a similar parse exception as described
>> previously (a NullPointer at OCLFactoryImpl:153 - when processing the
>> tuple specification).
>>
>> However, my interpretation of the OCL Spec is that the correct syntax
>> would use the 'TupleType' keyword instead of the first occurrence of
>> 'Tuple' in the above query. The parser seems to have other ideas,
>> returning org.eclipse.ocl.SyntaxException: 1:20:1:28 "Tuple" expected
>> instead of "TupleType".
>>
>> What is the simplest query in EMF OCL that will return me a set of
>> tuples?
>>
>> Thanks,
>> Daniel
>>
>> Christian W. Damus wrote:
>>> Hi, Daniel,
>>>
>>> See some replies in-line, below.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
>>>> Hello,
>>>>
>>>> I'm somewhat of an OCL MDT novice, so please bear with me! I'm
>>>> attempting to write my first queries which return tuplized results.
>>>> First off, I can't seem to find any documentation on the proper way
>>>> to write these queries and have taken all of my guidance from the
>>>> example in the 'MDT OCL Goes Generic' eclipsecon presentation. Is
>>>> there a more elaborate primer on this topic?
>>>
>>> Do you mean, besides the OCL Specification? You might try the
>>> introductory materials in the Open Model CourseWare project (OMCW)
>>> here at Eclipse.
>>>
>>>
>>>> My first observation is that I get a parse exception if I initialize
>>>> the Tuple with parentheses, it appears to want brackets (so Tuple{x
>>>> : T, x2 :T2,...}, not Tuple(x : T, x2 :T2, ...)). Is this accurate?
>>>
>>> The parentheses are used in the identification of a tuple *type* just
>>> as for collection types, e.g., Set(Employee) . The braces are used
>>> to construct a tuple value just as for collections, e.g., Set{self,
>>> self.manager} .
>>>
>>>
>>>> My current problem is that I'm getting a NullPointer that appears to
>>>> boil down to my specification of the Tuple fields. The following is
>>>> a simplified query that is not parsing:
>>>>
>>>> String queryString = "Set(Tuple{task : Task}) = " +
>>>> "let overrun : Set(Task) = " +
>>>> "self.tasks->select(t : Task | " +
>>>> "t.blownTask<>null) in " +
>>>> "overrun->collect(t | Tuple{" +
>>>> "task = t})";
>>>
>>> That should be:
>>>
>>> String queryString = "Set(Tuple(task : Task)) = " +
>>> "let overrun : Set(Task) = " +
>>> "self.tasks->select(t : Task | " +
>>> "t.blownTask<>null) in " +
>>> "overrun->collect(t | Tuple{t})";
>>>
>>> So, use parentheses in the tuple type reference and just fill in the
>>> tuple parts in the literal expression. The tuple parts are ordered,
>>> so the inferred type of the tuple literal in the collect expression
>>> is the same type as declared in the element type of the set type. At
>>> least, I think that should work ...
>>>
>>>> The full query I'm trying to write is tuplizing three fields, but
>>>> I've tried to cut this one down as much as I can. As I said, I get
>>>> a NullPointer when parsing this query, and when I unwind the stack
>>>> trace in debug mode, the trouble seems to start at line 2855 of
>>>> AbstractOCLAnalyzer (src.zip for build 1.2.3).
>>>>
>>>> At that point in the code, the parser is building instances of
>>>> TupleLiteralPart for each of the declared tuple fields. Each has
>>>> three parts - name, type and expr. In the debug console, 'name' is
>>>> assigned correctly ("task"), and so is 'type' (EClass for 'Task'),
>>>> but 'expr' is null because the object we're building from (an
>>>> instance of VariableCS) returns 'null' for getInitExpression().
>>>
>>> I suspect that what is happening, here, is that the parser is
>>> actually processing the misplaced tuple literal in the Set type
>>> reference? Tuple parts can have null values, and the 't' variable
>>> should be well-formed.
>>>
>>>> So what am I doing wrong? Is there something else I am supposed to
>>>> be doing is the query to make sure that 'task' is initialized?
>>>> Since it is being assigned in the 'collect' clause, what would be
>>>> the point?
>>>
>>> I suspect that it all stems from the parser getting confused by the
>>> misplaced tuple literal in your set type, instead of a tuple type.
>>>
>>>>
>>>> Thank you for your assistance,
>>>>
>>>> Daniel
|
|
|
| Re: VariableCS.initExpr = null when parsing a Tuplizing query [message #69099 is a reply to message #69078] |
Thu, 19 March 2009 20:44 |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Daniel,
As far as I know, a TupleType needs not have any parts at all (though
such wouldn't be useful). Certainly, there is no restriction on the
types of the parts.
This definitely looks like a bug.
cW
Daniel Tuohy wrote:
> Hi again!
>
> The problem is not that a tuple requires multiple components. My
> current guess is that a Tuple must have at least one component that is a
> primitive. My reason for suggesting this is:
>
> - Tuple(x : Foo, y : Bar, z : Baz, p : Integer)
> - Tuple(x : Foo, y : Bar, z : Baz, p : String)
> - Tuple(p : String)
> - Tuple(p : Integer)
>
> ...all parse correctly, however:
>
> - Tuple(x : Foo, y : Bar, z : Baz)
> - Tuple(x : Foo)
>
> ...cause a NullPointerException in the parser when processing the
> variable specs.
>
> It seems awfully silly, but is it possible that Tuples require a
> primitive component?
>
> Thanks,
> Daniel
>
> Daniel Tuohy wrote:
>> Christian,
>>
>> I may have stumbled across the error. I'm posting the solution in
>> case it is useful to other readers, and because I am curious for you
>> to verify the rationale.
>>
>> The query works if I add another field to the tuple, as in:
>>
>> String queryString = "let tuplized : Set(Tuple(task : Task, cost :
>> Integer)) = self.tasks->collect(t | Tuple{cost = t.cost, task =
>> t})->asSet() in tuplized->asSet()";
>>
>> I'm inclined to think that tuples are not well-formed unless they
>> specify at least 2 component parts, and that the parser just isn't
>> equipped to express that in an exception. Is that correct?
>>
>> Thanks,
>> Daniel
>>
>> Daniel Tuohy wrote:
>>> Christian,
>>>
>>> Thanks for your comments. Alas, I still can't seem to get a handle
>>> on the exact syntax. The real break may be getting a simple example
>>> of a well-formed query which returns a set of tuples, and then
>>> working from there.
>>>
>>> In thorough examination of both the OCL spec and your comments, I
>>> would think that the following is well-formed:
>>>
>>> String queryStr = "let tuplized : Set(Tuple(task : Task)) =
>>> self.tasks->collect(t | Tuple{t}) in tuplized->asSet()"
>>>
>>> Parsing this query generates a similar parse exception as described
>>> previously (a NullPointer at OCLFactoryImpl:153 - when processing the
>>> tuple specification).
>>>
>>> However, my interpretation of the OCL Spec is that the correct syntax
>>> would use the 'TupleType' keyword instead of the first occurrence of
>>> 'Tuple' in the above query. The parser seems to have other ideas,
>>> returning org.eclipse.ocl.SyntaxException: 1:20:1:28 "Tuple" expected
>>> instead of "TupleType".
>>>
>>> What is the simplest query in EMF OCL that will return me a set of
>>> tuples?
>>>
>>> Thanks,
>>> Daniel
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Daniel,
>>>>
>>>> See some replies in-line, below.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>> On Mon, 2009-03-16 at 13:23 -0400, Daniel Tuohy wrote:
>>>>> Hello,
>>>>>
>>>>> I'm somewhat of an OCL MDT novice, so please bear with me! I'm
>>>>> attempting to write my first queries which return tuplized results.
>>>>> First off, I can't seem to find any documentation on the proper way
>>>>> to write these queries and have taken all of my guidance from the
>>>>> example in the 'MDT OCL Goes Generic' eclipsecon presentation. Is
>>>>> there a more elaborate primer on this topic?
>>>>
>>>> Do you mean, besides the OCL Specification? You might try the
>>>> introductory materials in the Open Model CourseWare project (OMCW)
>>>> here at Eclipse.
>>>>
>>>>
>>>>> My first observation is that I get a parse exception if I
>>>>> initialize the Tuple with parentheses, it appears to want brackets
>>>>> (so Tuple{x : T, x2 :T2,...}, not Tuple(x : T, x2 :T2, ...)). Is
>>>>> this accurate?
>>>>
>>>> The parentheses are used in the identification of a tuple *type*
>>>> just as for collection types, e.g., Set(Employee) . The braces are
>>>> used to construct a tuple value just as for collections, e.g.,
>>>> Set{self, self.manager} .
>>>>
>>>>
>>>>> My current problem is that I'm getting a NullPointer that appears
>>>>> to boil down to my specification of the Tuple fields. The
>>>>> following is a simplified query that is not parsing:
>>>>>
>>>>> String queryString = "Set(Tuple{task : Task}) = " +
>>>>> "let overrun : Set(Task) = " +
>>>>> "self.tasks->select(t : Task | " +
>>>>> "t.blownTask<>null) in " +
>>>>> "overrun->collect(t | Tuple{" +
>>>>> "task = t})";
>>>>
>>>> That should be:
>>>>
>>>> String queryString = "Set(Tuple(task : Task)) = " +
>>>> "let overrun : Set(Task) = " +
>>>> "self.tasks->select(t : Task | " +
>>>> "t.blownTask<>null) in " +
>>>> "overrun->collect(t | Tuple{t})";
>>>>
>>>> So, use parentheses in the tuple type reference and just fill in the
>>>> tuple parts in the literal expression. The tuple parts are ordered,
>>>> so the inferred type of the tuple literal in the collect expression
>>>> is the same type as declared in the element type of the set type.
>>>> At least, I think that should work ...
>>>>
>>>>> The full query I'm trying to write is tuplizing three fields, but
>>>>> I've tried to cut this one down as much as I can. As I said, I get
>>>>> a NullPointer when parsing this query, and when I unwind the stack
>>>>> trace in debug mode, the trouble seems to start at line 2855 of
>>>>> AbstractOCLAnalyzer (src.zip for build 1.2.3).
>>>>>
>>>>> At that point in the code, the parser is building instances of
>>>>> TupleLiteralPart for each of the declared tuple fields. Each has
>>>>> three parts - name, type and expr. In the debug console, 'name' is
>>>>> assigned correctly ("task"), and so is 'type' (EClass for 'Task'),
>>>>> but 'expr' is null because the object we're building from (an
>>>>> instance of VariableCS) returns 'null' for getInitExpression().
>>>>
>>>> I suspect that what is happening, here, is that the parser is
>>>> actually processing the misplaced tuple literal in the Set type
>>>> reference? Tuple parts can have null values, and the 't' variable
>>>> should be well-formed.
>>>>
>>>>> So what am I doing wrong? Is there something else I am supposed to
>>>>> be doing is the query to make sure that 'task' is initialized?
>>>>> Since it is being assigned in the 'collect' clause, what would be
>>>>> the point?
>>>>
>>>> I suspect that it all stems from the parser getting confused by the
>>>> misplaced tuple literal in your set type, instead of a tuple type.
>>>>
>>>>>
>>>>> Thank you for your assistance,
>>>>>
>>>>> Daniel
|
|
|
Goto Forum:
Current Time: Tue Nov 04 05:01:00 EST 2025
Powered by FUDForum. Page generated in 0.06234 seconds |
Home