eclipse-gemoc / eclipse-gemoc/gemoc-studio-modeldebugging

MSE/MSEOccurrence schema is too closely tied to imperative operational semantics

Open
#103 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
6
Forks
14
PR merge metrics
No merged PRs in 30d

Description

We're developing a concurrent execution engine for operational semantics expressed in Henshin (see https://github.com/szschaler/henshin_xdsmls/) and are running into a problem with the way `MSE`s and `MSEOccurrence`s are currently structured.

At the moment, the metamodel for these assumes that there will always be an `EOperation` that is invoked on some specific target object, possibly with a set of concrete parameters, and possibly producing a specific result. None of these assumptions are valid for us, where an `MSEOccurrence` corresponds to a graph transformation rule being executed for a specific match on model elements in the current model graph.

While we can "emulate" (fake) an `MSE` and `MSEOccurrence` from a match, we have no easy way to go the other way. In fact, the information required to execute a step is currently stored in a sub-class of `SmallStep` in our implementation. This works for debugging, but will likely break tools that use the trace collected rather than directly interacting with the execution engine in an interactive manner.

Would it be possible to generalise the current metamodel by introducing a more abstract notion of `MSE` and `MSEOccurrence` and allowing different engines to contribute their own specialisations? Such contributions should probably also come with infrastructure code for displaying `MSEOccurrence`s (currently the display string is pretty much hard-coded) or for analysing traces based on such occurrences.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.