Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] [Dev]QVTi unbound variables

Hi

Within the current Area, an unbound Variable could be introduced in the BottomPattern, but there is no need to do so, so why allow unnecessary flexibility in what is intended to be a minimal flexibility representation?

More generally an unbound Variable might be referenced by a nested Pattern. If the Variable was in the BottomPattern, then the nested mapping would be similarly constrained. Restricting the declaration to the Guard avoids spurious restrictions on nested Mappings.

The possibility of 0 rather than 1 unbound variable we discussed and agreed that it was certainly necessary for top level structuring and might be appropriate for nested structuring too; further experience to guide semantics.

    Regards

        Ed

On 18/01/2013 12:32, Horacio Hoyos Rodriguez wrote:

Hello,

 

On the small description of QVTi in the QVTd wiki (http://wiki.eclipse.org/M2M/QVT_Declarative_Languages) it says that at each node (mapping) a new unbound variable is introduced by one of the input (domain) or middle guard patterns. What is the rationale behind this restriction? I understand limiting the number of unbound variables to 1 enforces the loop semantics of nested mappings, but I don’t understand why they should be introduced in guard patterns.

 

From a semantics view, I would think of guards as IF..THEN conditions. So variables and predicates in guard patterns should only be used to condition the evaluation of domains and middle bottom patterns. Additionally, if we consider the base structure of a QVTi transformation:

 

map container in transformation {

                map {                    -- L to M

                                check L() {

                                }

                …

}

map {                    -- M To R

}

}

 

Does having a guard in the first domains (the check L() in the example) makes sense? If it doesn’t and these initial domains are an exception then the proposed ocl invariant should reflect this.

 

Personally I think that the unbound variable should be introduced in check domains (L to M) or in MiddleBottomPatterns (M to R).

 

Regards,

 

Horacio Hoyos Rodríguez

EngD Student

University of York

 



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2639/6039 - Release Date: 01/17/13



Back to the top