Dear BRIDE/ROCK experts,

after a stormy discussion about some ideas related to model-driven tools for
RTT I made an attempt to glue ROCK with BRIDE using Xtext framework for textual
DSL development. The results are still in pre-alpha stage (yet) and not ready
to download, but I think that some issues have been already identified. I
wanted to share my preliminary experience report with the community, as I hope
some of you may find it interesting.

As a remainder - the long-term goal is to have a full-featured Eclipse-based
environment for design and development of RTT-based component systems. The
short-term goal is to interoperate between graphical notation of BRIDE and
textual syntax of ROCK in order to reuse code generation facilities of the
latter.

For those just interested in the outcome, please take a look at the bottom
of this email. For all the rest I have detailed some of the discovered
issues according to the tool they are related to, i.e. starting from RTT
meta-model, then ROCK and finally Xtext.

1. RTT meta-model

A number of minor issues with the RTT meta-model has been discovered and all of
them have been reported using bug tracking system. They are mostly related to
naming and cardinality of attributes, so I will not go into details here.

The most fundamental limitation of the RTT meta-model is related to modeling of
data-types for the generated code skeletons. Now it is only possible to use a
few of enumerated types (e.g., char, int, float, double and std::vector of
them). There is no such a limitation in RTT or ROCK and use of any C++ data
type (which is real-time safe) should be allowed. I think, that this is one of
the major issues, which need to be addressed. I have noticed some IDL-like
activity within the "bergamo" branch of the BRIDE repository, but I do not know
if/how it is going to be integrated with the RTT meta-model. Personally, I am
against inventing yet another IDL and prefer flexibility of ROCK, which allows
to use data-types coded directly in C++.

Another issue, is that RTT meta-model allows to design only "complete" systems.
For instance, cardinality of the outputPort.outputConnectionPolicy relationship
is set to 1, so all instances of the outputPort concept *must* be wired to some
input ports defined within *the same model*. Thus, it is not possible to create
a task context, which is not connected with any other entities. As a result, it
is not possible to use BRIDE for just a piece of an application. I think, that
this is a kind of design flaw, but it can be fixed rather easily.

Related to the above issue is mixing of "deployment" and "design" in the RTT
meta-model. These aspects are rather separated in ROCK (and I prefer this kind
of separation). For instance, the "name" attribute of a task context is not
specified until deployment section in ROCK. In RTT meta-model it needs to be
specified next to the task context itself.

There is also some minor clash between BRIDE and ROCK with respect to C++
namespaces in generated code skeletons. BRIDE generate task contexts as
'RTT::taskContext.namespace::taskContext.type' while ROCK as
'component.name::task.basename' (which I prefer). I see no point to make it
different and clearly there is a need for some kind of "convention" here.

In general, the RTT meta-model as defined in BRIDE is only a subset of the
implicit meta-model of ROCK. I have found a number of issues, which need to be
addressed. None of them seems to be really difficult to solve, but a kind of
agreement would need to be done between authors of BRIDE and ROCK. There is a
need to separate definition and deployment of task contexts in the meta-model,
but this is rather related to a more general issue of "composition".

2. ROCK (or "remarks on parsing internal DSLs")

I started with some ingenious definition of the ROCK component:

task_context "SimpleTask" do

output_port('out', 'double').
doc('documentation string').doc(doc('foo'))

operation('op1').returns('bool').returns('int')
end

It turns out, that this definition is perfectly acceptable for Orogen. However,
it is rather difficult to guess the outcome... - what will be the description
for the output port and what will be the return type for the operation? Of
course, one can easily fix these particular issues, but I think they are
illustrative examples of problems related to internal DSLs in general. Internal
DSLs need to be used with care, as there is (too) much freedom in using them.

I have assumed, that my goal is not to mimic the parser of Ruby, but to be as
close as possible to the *correct* use of ROCK. I started with a grammar
automatically generated by Xtext's wizard for the RTT meta-model. Then, I have
fine-tuned it step-by-step.

In general, the process of implementing subset of the ROCK syntax in Xtext is
not difficult. It definitely requires some time and effort (not to mention
about experience with the Xtext's internals...) to tune code formatting and
syntax highlighting. A kind of "template" for Ruby-like syntax would be more
than welcome. As far as I know this kind of feature/customization in not yet
available in Xtext.

3. Xtext

I have discovered two major issues related to use of Xtext for ROCK-like
syntaxes.

First issue is related to the 'port_driven' keyword in ROCK, which works
similar to 'private', 'public' and 'protected' keywords in C++. These keywords
modify attribute of an input port in ROCK and members of classes in C++
respectively. A single keyword modifies an attribute for *all* the following
entities and this kind of relationship is highly contextual. The problem is,
that it is not possible (or at least not easy) to express this kind of
relationship in BNF-like grammars. Thus, there is some post-processing of the
syntax tree required to set required attributes according to the context set up
by the keywords.

Second issue is related to representing bidirectional, opposite associations in
a textual notation. An example here is the ConnectionPolicy concept, which
links InputPort to OutputPort. The problem is, that user expects to express
these links only once (i.e., when specifying details of the connection), but
Xtext requires all the links to be reconstructed by the parser (i.e., it is
also required to reference a connection from the port's context).

I was not able to find a workaround for the above issue, but maybe some
advanced tuning of the meta-model can be used (e.g., some combination of the
'transient', 'volatile' and 'derived' properties).

In general, Xtext seems to be a good tool for the job, but there are still some
non-trivial issues to be solved. I am going to ask the Xtext community for some
hints, since I guess, that these issues are not only specific to this use-case.

*** Summary ***

Current state of development can be found using at the following location:
http://home.elka.pw.edu.pl/~ptrojane/orogen-syntax-editor.png

I did not wanted to bother you with screencast, but what you see is a result of
automatic formatting and custom syntax highlighting. I have added some custom
icons to the outline view. Code folding works out-of-the-box. TODO list include
code generation using templates both from BRIDE and ROCK (some general Eclipse
plugin-related stuff needs to be done for this).

As usual, comments are more than welcome!