Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master
Yes, I also have a feeling that semicolons are inconsistent.

Thanks for the article. Even though I don't mind not having semicolons, and in some languages this might actually be preferable, I think the author does make some good points, and the semicolon might make things easier for tools (and for some users).

The issue I have is about the mixture of braces and semicolons. In C/C++ sometimes you must put a semicolon after a closing brace, but not always, which is inconsistent. In our case, composite constructs use braces. I think that the rule should be that if the construct does not contain anything, then use a semicolon, otherwise use only braces. For example:

state S1;
state S2 { ... }

The alternative, to use semicolons everywhere doesn't look too good for me:

capsule {
  statemachine {
    state S1 {
      ...
    };
  };
};

Specially because the language is space insensitive, so this term could be written as

capsule{statemachine{state S1{...};};};

I'm not sure I like that.

On the other hand, the use of semicolons for simple declarations has one awkward case: actions. Consider

entry action 'p.sig().send();';

The combination of a semicolon in the action language and the core language doesn't look very good. But I don't know if there is a good way of dealing with this case.

PS: I noticed that in your example you have a transition with an empty action. These are now optional, as are transition names. So you could write 

transition from ServerInitial to ServerActive;


On Mon, Dec 14, 2015 at 4:37 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Looks good! I played around briefly with the improved syntax. What needs to be looked into is the use of semicolon (;)

Right now I have a feeling that it is rather inconsistent. I really do not know which principle actually is being used for when semicolon *must* be used, when it is *optional* to use, and when it is not allowed to be used at all. Here is my short example that I played around with:

model test {
description "This is my first model using the UML-RT textual syntax"
protocol Control {
out message request();
in message response();
}
capsule Client {
port pc: Control;
statemachine  {
initial ClientInitial
state ClientActive
transition Initial from ClientInitial to ClientActive action 'pc.request().send();';
}
}
capsule Server {
conjugate port ps : Control;
statemachine {
initial ServerInitial
state ServerActive
transition Initial from ServerInitial to ServerActive action '';
transition from ServerActive to ServerActive triggers { on request from { ps }} action 'ps.response().send();';
}
}
capsule Top {
fixed part client : Client;
fixed part server : Server;
connect client.pc to server.ps;
}
}

As you can see, the use of semicolon, feels a bit inconsistent. Could you look through this in general. Personally I do not have a strong preference in any direction, as long as it is consistent.

I actually read a article on DZone just the other day, regarding this about the use of semicolon in modern languages, which I guess fits this context pretty well I guess! :)


/Peter Cigéhn

On 12 December 2015 at 00:23, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
I've merged new improvements to the syntax:

* "simple" keyword for states is now optional: state S { ... } is the same as simple state S { ... } * state's body is optional, i.e. we can write state S instead of state S {} * port kinds supported: external port internal port relay port sap port spp port Port kind is optional and the default is "external": port * property (attribute, port and part) replication is optional and specifies only the upperbound (Note: if not specified, it will get values from the Ecore meta-model. So we need to either give the correct defaults in the meta-model or do some post-parsing processing)

But code generation won't work just yet.


On Fri, Dec 11, 2015 at 4:32 PM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
I've looked a bit into mixing languages with Xtext and liking Xtext and the CDT. Here are some preliminary findings:

1) It is possible to do "grammar mixins" in Xtext so it is theoretically possible to have the core grammar separate from the action language grammar, but...

2) the mixin is static so we would have separate mixin grammars for UMLRT+C++, UMLRT+Java, UMLRT+Alf, etc. This would require different file extensions for each such combination (which is how Xtext can determine which language it will be parsing).

3) There is no existing Xtext grammar C or C++, which is not very surprising because those are languages notoriously hard to parse (thanks to Ritchie and Stroustrup). I'm not even completely sure that Xtext's LL(*) parsers can deal with it (as C++'s grammar is context-dependent), and even if they can deal with it, the use of preprocessing directives becomes incredibly difficult to tackle. However...

4) in the code generator we already have an intermediate meta-model for a significant subset of C++. This could be transformed into an EMF meta-model and an Xtext grammar generated from it.

5) Some people have looked into integrating the CDT and Xtext, but going in the opposite direction: embedding Xtext miniDSLs in C++ code. These seem to have had limited success. 

6) Some people have worked on extending the CDT to make it "multilingual". But it seems to require modifications to the CDT itself, and the use of the CDT's own AST or something based on it, which will not be appropriate for many languages, including UML-RT.

7) It is possible to override the behaviour of Xtext-generated outline, formatter, content-assist, quick-fixes, etc. Hence we could delegate those activities to someone else, but it is not clear to me how to delegate to the CDT (or JDT), if at all possible.



On Fri, Dec 11, 2015 at 11:01 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
​Sure, you can handle it by having that in separate files. But I just have a feeling that we also need to have good support editing code snippets "inline" also, but possibly using some separate "view" or "floating window". Maybe the proposed code snippet view (as I mentioned above) used for editing code snippets in the graphical notation, also could be used for editing the code snippets in the textual notation. 

I'm not sure I can visualize how that would work. Something like clicking or hovering over the region of text with the action code would pop up the separate view or floating window, which would then have its contents synchronized with the main text editor? 


--
Ernesto Posse
Zeligsoft.com




--
Ernesto Posse
Zeligsoft.com


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev



_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Ernesto Posse
Zeligsoft.com

Back to the top