Xtext is the coolest of the cool projects at Eclipse today, and that's tough competition! Three of its four custodians, Sven, Sebastian, and Moritz, were there that Monday morning. We discussed the coolest things we could collectively conceive: Xcore, progeny of Ecore and Xbase. We decided to begin this new endeavor using a repository at github so we could immediately begin working as a team. (Of course we'll host this at Eclipse after we migrate EMF itself to Git.) Time flew yet much progress was made before the sun set on a great week.
We found time to write a proposal for a session at EclipseCon Europe 2011. If ever there was a Really Cool Thing,™ this definitely is it! Before I knew, I was back on a speeding plane, admiring the majesty that is Super Natural British Columbia.
I got home just in time for the final display of Vancouver's Celebration of Light. I was definitely in the mood to celebrate!
I'm extremely happy to have embarked on this cool quest. I look forward to excellent progress in the weeks to come. That vast desert of uncool is already fading from memory. To whet your appetite, here's how the Xcore model for the standard Library example looks:
This isn't just a pretty picture, we have a great deal that is working already! Don't just take my word for it, open source is a glass house; stay tuned. Of course all design decisions are subject to change. We look forward to feedback from the community.
Posts
10 comments:
Xcore looks very cool! Are there plans to make this new body language available in the normal Ecore editor, too?
A very cool name, indeed (from http://www.urbandictionary.com/define.php?term=xcore): Xcore - A suffix used to emphasise the extreme properties of just about any adjective, noun, verb, or even meaningless words.
I'm very much looking forward to the results and would like to support the work in any way (apart from $s I guess :-).
I took a brief look at the grammar and have a couple of questions/comments:
- The package name is not a URI but a qualified name. Is this to enable automatic generation of genmodel and interop with Java?
- The types of attributes and references refer to genmodel::GenBase. Will you automatically maintain a genmodel for each x/ecore file, to enable this?
- The Xcore model (whether serialized as text or XMI) may be a more interesting target for MDD than ecore, particularly how Xbase is integrated.
- In ecore, containment has a special role, but the containment structure is difficult to see. Would it be possible to support the nesting of XClasses, to make the containment structure more evident. E.g.
class Library {
class Book {
} [] books
}
- Is there a forum for discussing desired features/wishes?
I get several error markers in my clone of the git repo, including missing classes (e.g. import org.eclipse.xtext.xbase.scoping.LocalVariableScopeContext), fields (isUpdating in XcoreResource) and methods genModel.initialize(). What dependencies must be satisfied to build?
Eike,
We're not sure yet how best to support Xbase directly in Ecore. We'd like to focus on Xcore tools, which doesn't leave so much focus for the structured Ecore editor. I think such a thing would need to be supported in a textual form because no one would want to use structured creation to produce statements and expression. Annotations with a body entry would be a crude way to support it.
Hallvard,
You'll need to work with the Xtext nightly build to live on the bleeding edge. I'll keep patches updated in 354245 to keep up with EMF changes. It will be great to have you involved!
A qualified package name, from a textual language point of view, seems a better way to identify a package than an nsURI; the latter is more XML centric than human centric. In the absence of Xcore annotations, we'll map the simple name of the package to the nsPrefix and the qualified name will be used as the nsURI. We want the textual notation to be capable of completely specifying everything that's needed for the GenModel.
An Xcore resource contains the XPackage syntactically, but semantically an EPackage, a GenModel/GenPackage, and a Jvm Types model are induced each from the previous layer; those are contained as tertiary derived objects in the root of the resource. The details of how best to deal with Ecore models for which there is no Xcore source, or even for ones where there might not be a GenModel, need to be worked out as we look at implementing an interpretter.
We've been discussing the extent to which folks will want to work with Xcore as an API. Certainly tool writers will find that interesting. Obviously an API that includes a full behavioral language is far more complex than just an API for specifying structure so Xcore is inherently far more complex than Ecore. It's very easy to induce an Xcore resource from Ecore, so I expect Xcore to be interesting as an API primarily when you want control over behavioral details. Note there are context menu actions for "Convert to Ecore" and "Convert to Xcore" available on *.xcore and *.genmodel respectively so you can get a good idea of how the mapping works.
I really don't like the idea of allowing classes to nest. We'd like to avoid allowing packages to nest even. This type of syntactic sugar often turns into a form of semantic rat poison. Nested packages have caused no end of trouble over the years while contributing pretty much nothing of value.
Where best to discuss Xcore developments... Certainly the EMF newsgroup is appropriate using [xcore] as the subject line. The buzilla mentioned above works too.
It would be nice to have some commonality with OCLinEcore, but I guess even simple principles such as
Java: type name
OCL: name : type
make this too hard.
---------------
Applying at leasdt experience from OCLinEcore.
I recommend trailing ';' to allow error recovery, with everything space separated you can get very lost. (even Java has ';')
nested packages require package {}.
It would be good to add first class syntaxes for all the 'UML' feature map, subsets, ... magic.
Ed,
There's definitely a tradeoff between having a Java-like syntax verses something more OMG-traditional. Obviously we're leaning towards Java at this point.
Xbase specifies optional trailing semicolons. I've not put them in Xcore yet though likely we will. I'll defer to folks like Sven in terms of how much value such terminators provide. Certainly less noisy (less redundant) syntax has significant appeal. Note, for example, that there is no need to declare the type of the for-loop variable in the example.
In many ways, I'd rather not provide much support for things that don't map well to Java and aren't well supported directly in Ecore already. It's no secret that I'm not a big UML fan. Also, I think allowing nested packages has been a big mistake of the past so perhaps this is the right time to avoid repeating it.
I appreciate the effort and I am interested in it.
Good luck.
"Also, I think allowing nested packages has been a big mistake of the past so perhaps this is the right time to avoid repeating it. "
Interesting. So what is the relationship between Xcore and Ecore?
If Xcore is not 100% Ecore plus, is this a compatibility nightmare or a major evolution?
As an evolution, perhaps there is an analogy with Xbase/OCL, where it struck me that Xbase offered perhaps 90% of the capability of OCL in a much more practical and Java-friendly fashion.
If Xcore is the best 90% of Ecore, are we moving from the OMG-style information-based meta-models such as EMOF, OCL, UML to Xtext-style Concrete-Syntax-based meta-models?
This might work, certainly EGenericType deserves revisiting. But, if the new primary meta-models are driven by the pragmatics of a textual CS rather than modularity of the information, it might be a disaster.
I think that the missing piece is the textual CS to information Abstract Syntax mapping. Xtext does a fantastic job of the textual CS. For OCL I'm struggling to find model-driven automation for the CS to AS step.
I hope that Xcore is both a pragmatic textual XcoreCS for which perhaps multiple mappings support XcoreAS and Ecore.
Ed,
I think Xcore will provide easy evolution steps as supported by "Convert to Xcore" in the context menu for a *.genmodel. Nested packages can in principle just be exported to multiple separate *.xcore files. We've also been talking about how to split classes into separate files as well...
I certainly think it would be a great boon if we moved away from unreadable XMI representations to human readable notations. Of course for interchange, it would be great if we could still produce XMI on demand.
As for automating the mapping between concrete and textual syntax, that would be cool, but I'm content to do it by hand for Xcore/Ecore. It's tricky to try to support more than one expression/statement language in the one concrete syntax...
cool
Post a Comment