[news.eclipse.modeling.mdt.ocl] Re: OCL closures implementation

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Neil, Christian, Nicolas

I stumbled over the experimental closure() implementation a few days 
ago. It seems interesting. I see this has been raised as OMG Issue 
13944. The RTF committee is so busy that if we want to get this in
OCL 2.3 there are better chances if the submission is formatted ready
for inclusion in the RTF report.

I think the recursive specification difficulty can be easily cured by 
using infinite recursion of a helper function and a set that makes 
further recursion redundant.

After trying to use the closure iterator, I think that an object 
iterator form of closure is more fundamental than the collection 
iterator. This allows the start object to be included in the results, so 
a root and all its kids would be returned by

root.closure(it | it.kids)

whereas all the kids could be returned by

root.kids->forall(kid | kid.closure(it | it.kids))->asSet()

The collection iterator is nonetheless useful allowing the shorter

root.kids->closure(it | it.kids)

An object iterator is of course a new concept and so might bypass the 
specification in terms of iterate ordanance.

Do you think it worth appending an update to Issue 13944 along these lines?

	Regards
		
		Ed Willink

---------------------------------------------------------------------
On Mon, 14 Jul 2008 15:59:16 -0400, Christian W. Damus wrote:

Hi, Neil,

Actually, the closure iterator isn't really syntactic sugar.  The OCL 
specification suggests (requires?) that for any iterator _expression_ 
that is added to the standard library (not sure what that means; the 
question was raised as an issue), a specification of the iterator in 
terms of existing iterators (or the iterate _expression_) be provided.

The closure iterator is recursive by nature, and I don't think that this 
can be expressed using the iterate _expression_.  At least, I haven't 
tried very hard  ;-)

The important stopping condition is the encountering of an object that 
has already been added to the closure result collection before.  This, 
of course, is the classic means of dealing with recursion in cyclical 
structures.  The MDT implementation is roughly this:

  1. Collect the body-_expression_ values on the original source collection
      S into a new set R'.
        --> initialize the over-all closure result R to this set R'
  2. For new elements added to R in the previous pass (previous R' set),
      collect the body-_expression_ values into a new set R'.
        --> add these results to R
  3.  Repeat step 2 until R' has no results not already in R (i.e.,
       R' - R is the empty-set)

AFAIK, closure was never raised as a requested capability in the OCL 
specification.  Perhaps we should raise an enhancement issue?

HTH,

Christian


On Mon, 2008-07-14 at 15:23 -0400, Neil wrote:
> I'm aware that closure is not defined in the spec for OCL 2. I'm not
> clear why it's missing - too hard to implement or just not considered at
> the time.
>
> Is the implementation in Eclipse syntactic sugar for some variant of an
> OCL recursive function with stopping criteria? Or is something more
> involved being done behind the curtain?
>
> I'm trying to use OCL in Eclipse to define queries over a graph-like
> data structure (with possibly circular relations). So far the closure
> operator works perfectly, but I want to clarify how it's doing this.
>
> thanks
> Neil Ernst