Local variable in match block is misresolved as a property reference inside object pattern constraints

[mxmxmx888]

There appears to be a name resolution issue in the MDEO model transformation language. A local variable declared in a match block can be used in ordinary where clauses, but when referenced inside an object pattern constraint block, it is treated as if it were a property name instead of a local variable.

Actual behaviour:
The validator reports:
Could not resolve reference to Property named patientDuration

Expected behaviour:
patientDuration should be resolved as the local variable declared earlier in the same match block, not as a property of Patient.

[nk-coding]

the primary problem should be the missing support for operators such as <
added via #25
also already released by now
would this work for you or does any error still occur?

[szschaler]

There are two issues here, the lack of support for operators such as < as well as the lack of scoping to variables defined outside a block (so the forbid block doesn't see the variable defined in the main match).

BTW, I really struggle with the syntax for NACs. I think we need something that's a forbid on a match rather than on individual elements. So the above, should be written as:

match {
    patient: Patient {
        isMandatory = false
    }

    var patientDuration = patient.surgeryDuration

    forbid {
        existingAdmission: Admission {}
        existingAdmission.patientId -- patient
    }

    forbid {
        betterPatient: Patient {
            isMandatory = false
            surgeryDuration < patientDuration
        }
    }

    ...
}

which is different from

match {
    patient: Patient {
        isMandatory = false
    }

    var patientDuration = patient.surgeryDuration

    forbid {
        existingAdmission: Admission {}
        existingAdmission.patientId -- patient

        betterPatient: Patient {
            isMandatory = false
            surgeryDuration < patientDuration
        }
    }

    ...
}

because the former won't match if either an existingAdmission or a betterPatient can be found, while the latter only won't match if both an existingAdmission and a betterPatient can be found. At the moment, that difference cannot be expressed.

[nk-coding]

• regarding the scoping issue: as this is in a singular match, this should be the same scope (I think this was an incorrect error due to the not supported operator, but if there is still an issue pls let me know)
• regarding the textual syntax: I agree, I also already thought about that one for the textual. The reason why I did not do this yet was due to the graphical syntax, I'm open for suggestions there @szschaler . I know Henshin does this via names, which we could have after the forbid in the textual definition, but I'm not really sure if this is what we want. Numbers would be an option too, maybe even separate graphs as some tools do (which have their own drawbacks though)

[szschaler]

I quite like Henshin's nested names syntax

[nk-coding]

and in the textual DSL we then have this name basically like

forbid theName {
  a : TheClass { }
} 

?
or do you have a better idea?

[szschaler]

Yep, that's what I thought.