| Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master |
Hi,
Regarding the CSS3 Part, we never tried to implement anything like that. I’m not even sure that all modern web-browsers support this yet. But that’s part of one of the modules of the CSS3 Specification, and feasible “in theory”. In practice, I believe that most browser chose a “2-steps” parsing already for CSS (One pass for the structure, another pass for the values), so that makes it easy(ier) for them to support this.
This is specified in the CSS3 Custom Properties module (Very recently promoted to a Candidate Recommendation):
http://www.w3.org/TR/css-variables/#syntax
And one example:
--foo: if(x > 5) this.width = 10;
Note that the parenthesis do not need to encapsulate the entire _expression_. The only rule is that each parenthesis should be closed, and that the _expression_ doesn’t contain a “top-level” semicolon (As far as I understand, Semicolons can appear within groups such as parenthesis or quotes or brackets)
So this would be invalid:
--foo: if (x > 5) this.width = 10; ;
But this would be valid:
--foo: if (x > 5) { this.width = 10; } ;
HTH,
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Ernesto Posse
Envoyé : lundi 14 décembre 2015 16:52
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master
Hi Camille,
On Mon, Dec 14, 2015 at 10:44 AM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
Hi,
The issue in general of mixing languages in a single grammar is a complex one, because the grammars/parsers can easily be conflicting.
In general, there are two ways for handling this issue (Including more than 2 languages in the same file, so mixin grammars are not really an option here):
- An abstract syntax tree (e.g. EMF Model): you don’t have parse issues because there is no grammar (Or a low level grammar such as XMI)
o That’s the approach taken by e.g. Jetbrains MPS (Meta-programming System), which provides a “text-like” editor, which actually is not text-based at all (it is in reality a set of inlined editable boxes, with a lot of support for Ctrl + Space, and each box is a node of the Abstract Syntax Tree)
I've looked at MPS and that approach is very interesting indeed, but Simon doesn't want to go this way.
o But that’s not the XText philosophy at all
- The CSS3 Grammar provides a mechanism for custom expressions, with a single constraint: un-closed parenthesis/brackets are forbidden. Everything else is free-text, that will be handled by a separate parser (From the CSS Parser’s point of view, this is a String). This means that you need several parsers (One for CSS, and one for each supported language), and it can be a nightmare to implement proper formatting/coloration within the “free-text” part of the _expression_, but then you have a good flexibility
This is very interesting. I wasn't aware of this approach.
A CSS3 example:
MyElement {
myValue: java(if (this.getValue() == true) { return “something”; });
}
Note that everything between after the colon (including java()) will be considered as a String by the CSS Parser, because we respect the key rule: parenthesis are closed, as well as brackets (And we have an optional semicolon at the end :) )
With a better formatting:
MyElement {
myValue: java(
if (this.getValue() == true) {
return “something”;
}
);
}
The main benefit from this approach is that you can mix different languages in the same text file, with several independent parsers. The main issue is that formatting/coloration can be more complex (But probably not impossible). And this would work with XText too, although requiring some non-trivial glue.
So the "top-level" parser would be a CSS3 parser which delegates part to an Xtext parser and part to another (e.g. a C++) parser?
Do you recommend any links for documentation?
Regards,
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : lundi 14 décembre 2015 16:20
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master
Hi,
Regarding the case with action and that you get those "double semicolons", I have been a bit "annoyed" by as well. As you say, it might be hard to deal with that case. But I have a feeling that this boils down to the core aspect of how you "weave" the target language together with the UML-RT language. How do we get the support for completion, syntax coloring, and formatting within the "parent" UML-RT language?
Is it possible to avoid having to write the code snippet within quotes? Can we go back to have the code snippet within { and } and thus don't have a semicolon at the end? Can the grammar handle some line-break oriented part, i.e. that you write the target action code on its own separate lines. The main aspect then will be how the "block" of target code is ended. As I have indicated before, I think that this area will be the one of the most important aspect to solve in a good way...
/Peter Cigéhn
On 14 December 2015 at 15:37, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
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
_______________________________________________
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
_______________________________________________
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