tag:blogger.com,1999:blog-62557582246074665652024-03-19T04:19:55.637+01:00Sebastian Zarnekow's BlogThoughts of a passionate programmerAnonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-6255758224607466565.post-69203032188257721902017-05-15T16:28:00.000+02:002017-05-15T21:08:17.288+02:00Moving On - Part 2<div dir="ltr" style="text-align: left;" trbidi="on">
A big thank you for all the nice feedback and encouraging words that I received after my announcement to leave SMACC. Now, that I’ve had my last day at the company, I think it’s time to raise the curtain. And there aren’t too many surprises behind it, I guess.<br />
From 01 June 2017 on, I’ll be a freelancer and professional consultant. I will build solutions for software developers and solve language engineering problems for my customers. My goal is to help developers and domain experts sharpening their tools, so that they can tackle their business challenges more efficiently.<br />
Also I will work closely with the great people and friends from <a href="https://www.itemis.de/" target="_blank">itemis</a> and be part of the growing team in the <a href="https://www.google.de/maps/dir//Friedrichstra%C3%9Fe+68,+10117+Berlin/" target="_blank">Berlin branch</a>. Of course I’m looking forward to contributing to <a href="http://www.eclipse.org/Xtext/" target="_blank">Xtext</a> again. After being absent for more than 15 months, a few things changed in the project, but there are plenty of interesting topics to tackle in the framework, for sure. Time to get my hands dirty!<br />
Long story short: I’m happy to be back :)<br />
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com1tag:blogger.com,1999:blog-6255758224607466565.post-60911942118708846142017-04-17T23:04:00.000+02:002017-04-17T23:04:57.107+02:00Why DSLs?<div dir="ltr" style="text-align: left;" trbidi="on">
A lot has been written about <a href="http://lmgtfy.com/?q=domain+specific+languages">domain specific languages</a>, their purpose and their application. According to the ever changing wisdom of wikipedia, a DSL “is a <a href="https://en.wikipedia.org/wiki/Computer_language">computer language</a> specialized to a particular application <a href="https://en.wikipedia.org/wiki/Domain_(software_engineering)">domain</a>. This is in contrast to a <a href="https://en.wikipedia.org/wiki/General-purpose_language">general-purpose language</a> (GPL), which is broadly applicable across domains.” In other words, a DSL is supposed to help to implement software systems or parts of those in a more efficient way. But it begs the question, why engineers should learn new syntaxes, new APIs and new tools rather than using their primary language and just get the things done?<br />
<br />
Here is my take on this. And to answer that question, let’s move the discussion away from programming languages towards a more general language understanding. And instead of talking abstract, I’ll use a very concrete example. In fact one of the most discussed domains ever - and one that literally everyone has an opinion about: The weather.<br />
<br />
We all know this situation: When watching the news, the forecaster will tell something about sunshine duration, wind speed and direction, or temperature. Being not a studied meteorologist, I can still find my way through most of the facts, though the <a href="https://en.wikipedia.org/wiki/Probability_of_precipitation">probability of precipitation</a> always gives me a slight headache. If we look at the vocabulary that is used in an average weather forecast, we can clearly call that a domain specific language, though it only scratches the surface of meteorology. But what happens, when two meteorologists talk to each other about the weather? My take: they will use a very efficient vocabulary to discuss it unambiguously.<br />Now let’s move this gedankenexperiment forward. There are approximately <a href="https://everything2.com/title/Finnish+words+for+snow">40 non-compound words</a> in the Finnish language that describe snow. Now what happens, when a <i>Finnish</i> forecaster and a <i>German</i> news anchor talk about snowy weather conditions and the anchorman takes <i>English</i> notes on that? I bet it is safe to assume that there will be a big loss of precision when it comes to the mutual agreement on the exact form of snowy weather. And even more so, when this German guy later on tries to explain to another Finn what the weather was like. The bottomline of this: common vocabulary and language is crucial to successful communication.<br />
<br />
Back to programming. Let’s assume that the <i>English</i> language is a general purpose programming language, the <i>German</i> guy is a software developer and the <i>Finnish</i> forecaster is a domain expert for snowy weather. This may all sound a little farfetched, but in fact it is exactly how most software projects are run: A domain expert explains the requirements to a developer. The dev will start implementing the requirements. Other developers will be onboarded on the project. They try to wrap their head around the state of the codebase and surely read the subtleties of the implementation differently, no matter how fluent they are in English. Follow-up meetings will be scheduled to clarify questions with the domain experts. And the entire communication is prone to loss in precision. In the end all involved parties talk about similar yet slightly different things. Misunderstandings go potentially unnoticed and cause a lot of frustration on all sides.<br />
<br />
This is where domain specific languages come into play! Instead of a tedious, multi-step translation from one specialized vocabulary to a general purpose language and vice versa, the logic is directly implemented using the domain specific terms and notation. The knowledge is captured with fewer manual transformation steps; the system is easier to write, understand and review. This may even work to the extent that the domain experts do write the code themselves. Or they pair up with the software engineers and form a team.<br />
<br />
As usual, there is no such thing as free lunch. As long as your are not <a href="http://powerlisting.wikia.com/wiki/Omnilingualism">Omnilingual</a>, you should probably not waste your time learning Finnish by heart, especially when you are working with Spanish people next week, and the French team the week thereafter. But without any doubt, fluent Finnish will pay off as long as your are working with the Finns.<br />
<br />
A development process based on domain specific languages and thus based on a level of abstraction close to the problem domain can relief all involved people. There are fewer chances for misunderstandings and inaccurate translations. Speaking the same language and using the same vocabulary naturally feels like pulling together. And that’s what makes successful projects.</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-90692373601982550662017-04-10T13:46:00.000+02:002017-04-10T13:46:13.665+02:00Moving on<div dir="ltr" style="text-align: left;" trbidi="on">
<span id="docs-internal-guid-aef576b6-57ae-b6b1-d444-9d6b8d0ef9f9"><span style="font-family: Arial; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">After an exciting journey of 15 months as the Director Engineering at SMACC, I decided to move on. It was not an easy decision to make, though it’s still one that I wanted to make. In the past year I made many new friends, met great people, and had the chance to work in a super nice team. It was a great time with plenty of challenges, important learnings and great fun. But I also realized that I was missing the time as a technical consultant. Language engineering always was and still is a strong passion of mine. So I figured it’s about time to move on and refocus. Xtext, Eclipse, Language oriented programming - exciting times ahead. Keeping you posted ...</span></span></div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com3tag:blogger.com,1999:blog-6255758224607466565.post-59367029922206208002015-11-06T12:50:00.001+01:002015-11-06T12:50:23.881+01:00Improved Grammar Inheritance<div dir="ltr" style="text-align: left;" trbidi="on">
Since the very first day of <a href="http://www.xtext.org/" target="_blank">Xtext</a>, it was possible to extend another grammar to mixin its rule declarations to reuse or specialize them. For most use cases that was straightforward and a perfect match. For others it was rather cumbersome so far because the original declaration was no longer reachable from the sub-language. Copy and paste was the only solution to that problem. The good news? The situation changes with Xtext 2.9 significantly.<br />
The newly introduced <span style="font-family: "courier new" , "courier" , monospace;">super</span> call allows to override a rule and still use its super implementation without the need to duplicate it. Along with <span style="font-family: "courier new" , "courier" , monospace;">super</span>, Xtext 2.9 also provides a way to call inherited or locally declared rules explicitly. Explicit rule calls will overrule the polymorphism that is usually applied in the context of grammar inheritance. As a language library designer you get fine grained control over the syntax, even if your language is supposed to be extended by sub-languages.<br />
But let's look at an example:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;"><span style="color: #b45f06;"><b>grammar</b></span> SuperDsl<br /> <span style="color: #b45f06;"><b>with</b></span> org.eclipse.xtext.common.Terminals<br />..<br />Element:<br /> <span style="color: #6fa8dc;">'element'</span> <span style="color: #e69138;">name</span>=ID<br />;
<br />
Thing:<br /> <span style="color: #6fa8dc;">'thing'</span> <span style="color: #e69138;">name</span>=SuperDsl::ID<br />;<br /><span style="color: #b45f06;"><b>terminal</b></span> ID: (<span style="color: #6fa8dc;">'a'</span>..<span style="color: #6fa8dc;">'z'</span>)+;</span></blockquote>
<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;"><span style="color: #b45f06;"><b>grammar</b></span> SubDsl <span style="color: #b45f06;"><b>with</b></span> SuperDsl<br />..<br />Element:<br /> super <span style="color: #93c47d;">// 1; or super::Element</span><br /> | <span style="color: #6fa8dc;">'element'</span> <span style="color: #e69138;">name</span>=super::ID <span style="color: #93c47d;">// 2</span><br /> | <span style="color: #6fa8dc;">'element'</span> <span style="color: #e69138;">name</span>=Terminals::ID <span style="color: #93c47d;">// 3</span><br />;<br /><span style="color: #b45f06;"><b>terminal</b></span> ID: <span style="color: #6fa8dc;">'id'</span>;</span></blockquote>
Here we see different use cases for the <span style="font-family: "courier new" , "courier" , monospace;">super</span> call and also for qualified rule calls. The first occurrence of <span style="font-family: "courier new" , "courier" , monospace;">super</span> (1) illustrates the shortest possible notation to reach out to the super implementation. If you override a rule and want to use the original declaration in the rule's body, you can simply call <span style="font-family: "courier new" , "courier" , monospace;">super</span> from there.<br />
It is also possible to use a <span style="font-family: "courier new" , "courier" , monospace;">qualified::RuleCall</span>. Qualified invocations point directly to the referenced rule. The qualifier can either be a generic <span style="font-family: "courier new" , "courier" , monospace;">super</span> qualifier (2) or an explicit language name (3). The latter provides a way to skip the immediate super language and reach out to its parent. This offers great flexibility. You can ensure that you call the rule from your own grammar, even if a sub-language will override the declaration. The benefit is illustrated by the rule <span style="font-family: "courier new" , "courier" , monospace;">Thing</span>. It calls the <span style="font-family: "courier new" , "courier" , monospace;">ID</span> declaration from <span style="font-family: "courier new" , "courier" , monospace;"><span style="font-family: "courier new" , "courier" , monospace;">Super</span>Dsl</span> explicitly thus it will also do so from the <span style="font-family: "courier new" , "courier" , monospace;">SubDsl</span>. As long as you do not explicitly override the declaration of <span style="font-family: "courier new" , "courier" , monospace;">Thing</span>, its syntax will not change in any inheritor from <span style="font-family: "courier new" , "courier" , monospace;"><span style="font-family: "courier new" , "courier" , monospace;">Super</span>Dsl</span>.<br />
Long story short: <span style="font-family: "courier new" , "courier" , monospace;">super</span> calls add a lot more flexibility for language mixins and greatly reduce the need to copy and paste entire rule bodies in the sub-language. Go ahead and <a href="https://www.eclipse.org/Xtext/download.html" target="_blank">download</a> the latest milestone to give it a try!</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com12tag:blogger.com,1999:blog-6255758224607466565.post-80580463713550418262015-10-22T09:35:00.001+02:002015-10-23T09:56:07.262+02:00The Xtext Grammar Learned New Tricks<div dir="ltr" style="text-align: left;" trbidi="on">
Since the Xtext 2.9 release is around the corner - and you've for sure read about the upcoming <a href="https://vimeo.com/141201249" target="_blank">support for IntelliJ IDEA</a> or Xtext editors in the browser -, it's time to unveil some of the new features of the Xtext grammar language itself. In a nutshell the enhancements address a couple of long standing feature requests and non-critical issues that we had. But especially complex grammars sometimes required duplicated or repetitive parts to implement the language syntax. We felt that it was about time to get rid of these idioms.<br />
Long story short: In the next version the grammar language will support a couple of new features:<br />
<ol style="text-align: left;">
<li><span style="color: #6aa84f;"><span style="font-family: "Courier New",Courier,monospace;">/* SuppressWarnings[all] */</span></span>: The severity of errors and warnings in a grammar file can be customized on a per project level since Xtext 2.8. But sometimes you don't want to disable the validation rule completely just to get rid of one particular false positive (<i>False positive?!?</i> you think? Stay tuned, I'll elaborate on that in a separate post). For that purpose it's now possible to mute a certain validation rule for a selected element, a rule or the entire grammar.</li>
<li><span style="color: #b45f06;"><b><span style="font-family: "Courier New",Courier,monospace;">super</span></b></span> calls and grammar mixins: Xtext 2.9 renders our former advise 'You have to copy the parent rule into your sub-language' obsolete. Eventually it is possible to simply use a super call instead.</li>
<li>A long standing <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=263773" target="_blank">feature request</a> for the grammar described a means to extract common parts of parser rules without screwing up the ecore model. The newly introduced parser <span style="color: #b45f06;"><span style="font-family: "Courier New",Courier,monospace;"><b>fragments</b></span></span> allow to normalize production rules that formerly required copy'n'paste, e.g. due to left factoring. Fragments even sport smarter inference of the ecore model when it comes to multiple inheritance.</li>
<li>Last but not least, the new <a href="http://www.ecma-international.org/ecma-262/6.0/#sec-grammar-notation" target="_blank">JavaScript specification</a> was an inspiration for conditional alternatives in a grammar definition. Advanced language use cases may require to enable or disable a decision path deep down in some recursive chain of rule calls. Until now there was no concise way to support something like that. This limitation led often to dozens of copied rules if a syntax required to support conditionally enabled or disabled branches. Parameterized rule calls remove that limitation and enable much more expressive notations.</li>
</ol>
I'll explain all these new features in-depth in a short blog series to make sure that every bit of it gets proper attention. Make sure to follow-up if you are curious about them.</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com3tag:blogger.com,1999:blog-6255758224607466565.post-65466691472003021752014-11-03T22:17:00.003+01:002014-11-03T22:17:51.307+01:00After EclipseCon is Before EclipseCon<div dir="ltr" style="text-align: left;" trbidi="on">
Now that the EclipseCon Europe 2014 is over, it's time to focus on the next big community event: <a href="https://www.eclipsecon.org/na2015" target="_blank">EclipseCon North America 2015</a> - especially since the deadline for the call for paper is already approaching. Better get your session proposal ready soon, if you want to share something new, cool, interesting or enlightening with your peers. If you are really fast, you may even reach the deadline for the early bird picks. Chances won't get better.<br />
In other words: San Francisco. March 2015. EclipseCon. <a href="https://www.eclipsecon.org/na2015/cfp" target="_blank">Submit</a> now!<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.eclipsecon.org/na2015/cfp" target="_blank"><img alt="https://www.eclipsecon.org/na2015/cfp" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNfnplIjgZ-oPC-Fm2PAbQEcSKrTr4amJcamhGsvzV6TEyBt3OsEn7synYz9qJomzxVWd8mT_-zZXkIZtYHnxUwr-OrMe1NhRG8tNg19d0THLA0rpoabTKhbGcLL8L6kEOS-DkLT0rjeg/s1600/logo_eclipsecon_na_2015.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
In case you don't know it yet: EclipseCon North America will again feature theme days that focus on special topics, one of those will be dedicated to <a href="http://www.xtext.org/" target="_blank">Xtext</a>. If you want to share insights about your application of domain-specific languages, how you solved challenges in your language implementation or how you use the framework in general, I can only encourage you to submit a talk for the Xtext track.<br />
As every year, I expect EclipseCon to be a great community event with deep technical content. Like nowhere else, you can get in touch with the committers of the various Eclipse projects, discuss solutions and have a great time. So even if you don't plan to <a href="https://www.eclipsecon.org/na2015/cfp" target="_blank">submit a proposal</a>, make sure to save the date: March 9 - 12 in sunny California, EclipseCon NA! <br />
Still not convinced? Check out the <a href="https://www.flickr.com/groups/2721056@N23/" target="_blank">impressions</a> from <a href="https://www.flickr.com/photos/108559379@N08/sets/72157642550951475/" target="_blank">past</a> EclipseCons and see what you are going to miss!</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com2tag:blogger.com,1999:blog-6255758224607466565.post-85528401804771001972014-10-06T19:10:00.003+02:002014-10-06T19:10:45.266+02:00Musing about Eclipse UX Metaphors: The Blocking Build<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<br />
<h3 style="text-align: left;">
tl;dr</h3>
For the upcoming version of <a href="http://www.xtext.org/" target="_blank">Xtext</a> we are revising the approach to building. It appears to be promising to rethink the overall lifecycle of the Xtext builder to aim at:<br />
<ol style="text-align: left;">
<li>Better user experience by introducing a non-blocking build infrastructure</li>
<li>Improved performance due to improved parallelization</li>
<li>Incremental builds also on the command line</li>
</ol>
<h3 style="text-align: left;">
The Problem </h3>
The Xtext framework implements an Eclipse builder and is thereby immediately affected by the builder's user experience metaphor (even bad experience is still experience). Whenever a file is saved or a project is explicitly built, the user is essentially locked out from doing work in the editor.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrCgx1hLVdLrEHzOC_T_mWp87KPLTiyVUpFVlBwZpXDIW1WanxOE326I_A8DbPzQCw8R9kiXBu_NHvXsOGxU1z1Q8nnjtn7ORfX400PcXd9-_NCrhF3vSBc1g1u_9iOInjZaonFlhTI6E/s1600/building.png" imageanchor="1"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrCgx1hLVdLrEHzOC_T_mWp87KPLTiyVUpFVlBwZpXDIW1WanxOE326I_A8DbPzQCw8R9kiXBu_NHvXsOGxU1z1Q8nnjtn7ORfX400PcXd9-_NCrhF3vSBc1g1u_9iOInjZaonFlhTI6E/s1600/building.png" height="177" title="" width="400" /></a></div>
<div style="text-align: center;">
<i>Go Home, Eclipse! You're drunk!</i> </div>
That's not because the editor isn't generally usable during the build. But it turns out, that it becomes quite a habit to Eclipse users to save early and save often. As soon as you wrote some code and you save the file that you're working on, the builder kicks in and tries to validate the new file state. Since you are continuing to edit, it's quite likely that you hit save again and are confronted with that modal dialog with greetings from the 90s. Of course you don't see this message all the time when you save a file since the incremental build is usually quite fast, but when you see it, it is definitely not what you expected.<br />
<br />
<h3 style="text-align: left;">
Some Background</h3>
<div style="text-align: left;">
Generally speaking, the Eclipse builder is responsible to produce artifacts from the source files in a project. There may be different builders configured for the very same project and the term artifact does not only describe compilation results in the form of new files, but also validation markers. While a builder is running for a project, it holds an acquired lock not only for that project including its contained files and folders but for the entire workspace. This ensures that there are no intermitted events that remove or modify any state on disk (details have been discussed <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=198591" target="_blank">here</a>). And this is where the trouble starts from the users perspective.</div>
<div style="text-align: left;">
On the one hand, the locking prevents from unexpected modifications within Eclipse, on the other hand it gets in the way of users since they can no longer work without interruption. The thing was apparently designed to ensure consistency within the workspace between sources and compilation result. But if you look into the dirty corners, the paid price is way too high. The blocking mechanism introduces only the impression of safety but can never guarantee it. Literally every external process may still perform I/O operations on the very same files and the build would go bananas since the state known to Eclipse is no longer in sync with the actual state on disk. But that's probably another can of worms that is not subject of this post. Instead let's focus on ways to improve the situation which may lead to a more responsive UI.</div>
<h3 style="text-align: left;">
Action Items</h3>
<div style="text-align: left;">
For Xtext, we are currently analyzing how we can change the way we build files and projects. Rather than getting in the way of the user, we are thinking about performing the build in the background without unnecessary blocking. The main goal with that regards is to move the complete build out of the coarse grained project lock and break it into manageable, smaller pieces. E.g. as soon as the files are loaded, they don't need to be locked anymore. In the validation phase only the markers are written but not the entire files. For incremental builds, only a small subset of files needs to be considered in the first place.</div>
<div style="text-align: left;">
This breakdown of locking is desirable on various level. First and foremost, the user experience would be improved a lot since Xtext would present fewer blocking dialogs to the user. Another positive effect is that the build and its lifecycle would be essentially decoupled from the Eclipse builder and its related UI components. By factoring out the build cycle, Xtext can support incremental compilation on the command line, too.</div>
<div style="text-align: left;">
In times of many-cores, it also becomes more and more interesting to parallelize the build to go full throttle with todays CPUs. The leverage the potential there, the build process itself has to be analyzed carefully. The Xtext build inherently runs in multiple passes that are currently strictly sequential, especially in the context of Eclipse projects. These steps are performed for each individual project during a build.</div>
<ol style="text-align: left;">
<li>First of all, the resources in a project have to be indexed to collect all the reachable names and derive an index structure that can be seen as a global symbol table.</li>
<li>After all symbols and names are known, the cross references are resolved and their resolution state is cached as reference descriptions. Currently also the validation is performed on that stage but that can be seen as step 2.5</li>
<li>The last step is the code generation. All resources are processed to create derived artifacts from them.</li>
</ol>
There are already means in Xtext to perform some steps in parallel. E.g. the loading of files into memory for stage (1) can be done in parallel rather than sequentially since Xtext 2.0. In the future, we want to improve on that and allow a lot more parallelization. Given that the build would be decoupled from the Eclipse builders lifecycle, we could index all the resources in the workspace at the same time. In phase (1), there is no need for one project to wait for another. Multiple projects would be processed in parallel rather than sequentially. Also the reference resolution can be done in parallel - at least if the projects do not depend on each other transitively. For the code generation, there is already support for parallelization since Xtext 2.7, but there's still room for improvements, e.g. we could not only generate resources within a single project in parallel but also run the full build concurrently for multiple projects.<br />
But there's even more that we are discussing right now about the way
Xtext projects are build within Eclipse. We are looking into means to
preserve the index state if a project is closed by the user, for example. Instead of
rebuilding the entire project, the builder state would be available
immediately after the project is reopened, similar as with plain Java projects. Also the general handling of
archives and resources in these archives is under review. For bigger
projects, it may pay off to have precomputed information available that
is packaged together with the resources in the archive.<br />
In the end, the overall goal is to improve the perceived performance and the responsiveness of the IDE. Never ever should a user action be blocked by some task the IDE is performing in the background. The build should also be decoupled from the Eclipse infrastructure. With that regards, the contracts for each build step have to be sharpened and of course correctness should not be traded for concurrency. Exciting times!</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com7tag:blogger.com,1999:blog-6255758224607466565.post-2853466814242326342014-10-03T12:56:00.000+02:002014-10-03T15:07:20.375+02:00Testing multiple Xtext DSLs<div dir="ltr" style="text-align: left;" trbidi="on">
Recently there was a <a href="https://www.eclipse.org/forums/index.php/t/823170/" target="_blank">question</a> in the <a href="https://www.eclipse.org/forums/index.php?t=thread&frm_id=27" target="_blank">Eclipse forum</a> about testing multiple <a href="http://www.xtext.org/" target="_blank">Xtext</a> languages. The described scenario involves two language and one should have cross references to the other. Since this usecase caused some <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=439451" target="_blank">headaches</a> in the past, <a href="https://plus.google.com/+MichaelVorburgerCH/posts" target="_blank">Michael Vorburger</a> provided a <a href="https://git.eclipse.org/r/#/c/31753/" target="_blank">patch</a> (Thanks for that!) that adds information about that particular topic to the official Xtext <a href="https://www.eclipse.org/Xtext/documentation.html#testing" target="_blank">documentation</a>. The updated docs are available since the recent <a href="https://www.eclipse.org/Xtext/releasenotes.html" target="_blank">2.7 release</a>. To provide some additional guidance, I hacked a small <a href="https://github.com/szarnekow/testing-multiple-dsls" target="_blank">example</a> that can be used as a blueprint if you want to get a jump start on that issue. This example also documents briefly how Xtext's unit test facilities can be used for effective language testing.<br />
<br />
Key to testing the infrastructure of a DSL is the setup of a proper test environment. The Guice services have to be registered, EMF has to be initialized and obviously everything has to be cleaned up again after a test has been executed. For that purpose, Xtext provides a dedicated Junit4 <a href="https://github.com/eclipse/xtext/blob/master/plugins/org.eclipse.xtext.junit4/src/org/eclipse/xtext/junit4/XtextRunner.java" target="_blank">test runner </a>that uses an <a href="https://github.com/eclipse/xtext/blob/master/plugins/org.eclipse.xtext.junit4/src/org/eclipse/xtext/junit4/IInjectorProvider.java" target="_blank">injector provider</a> to do the initialization. The nice thing about that approach is that you can directly inject the necessary services into your unit test class. Exaclty as you are used to in your production code, too.<br />
<script src="https://gist.github.com/szarnekow/ad2369160bee7b42e619.js?file=UnitTest.xtend"></script><br />
When it comes to testing multiple DSLs, basically the same infrastructure can be used, though you have to make sure, that all involved languages are properly initialized. For that purpose, a custom injector provider has to be derived from the one, that was already generated for your language. The to-be-written subclass needs to takes care of all the prerequisites and register the dependent languages. This mainly involves delegation to their injector providers.<br />
<script src="https://gist.github.com/szarnekow/ad2369160bee7b42e619.js?file=MultiLangInjectorProvider.xtend"></script><br />
Now that the setup is ready, we can test cross references between multiple DSLs. It is important to know that these references are only properly resolved if all models are available in the same resource set. That's why we need to use an explicit resource set in the tests. Besides that, it's the programming model that you know from Xtext and EMF in general.<br />
<script src="https://gist.github.com/szarnekow/ad2369160bee7b42e619.js?file=MultiLangTest.xtend"></script><br />
A complete examplary test is available on <a href="https://github.com/szarnekow/testing-multiple-dsls/blob/master/zarnekow.goodbye.tests/src/zarnekow/goodbye/tests/LinkingTest.xtend" target="_blank">Github</a>.</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com3tag:blogger.com,1999:blog-6255758224607466565.post-92009178341009355022013-03-22T18:38:00.001+01:002013-03-22T18:38:14.801+01:00EclipseCon 2013 - Last Minute Preview<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<a href="http://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/imagecache/slideshow_full/boston-harbor%20fps.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="" border="0" class="imagecache imagecache-slideshow_full imagecache-default imagecache-slideshow_full_default" height="132" src="http://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/imagecache/slideshow_full/boston-harbor%20fps.png" title="" width="200" /></a>Now that I know how to find the <a href="http://www.mbta.com/schedules_and_maps/subway/lines/?route=SILVER" target="_blank">way</a> from the Logan Intl Airport to the EclipseCon venue at the <a href="http://www.seaportboston.com/meetings-and-events/trade-shows-and-exhibits.aspx" target="_blank">Seaport WTC</a> in <a href="http://www.restaurantweekboston.com/" target="_blank">Boston</a>, it's time for some shameless advertising. Since the conference schedule is again packed with deep technical content and all of you have only limited time, I think it's only fair to tell you in advance what you should expect from the sessions that I am giving (of course all of them are highly recommended ;-).<br />
<br />
<br />
<b>Mon 1:00PM - 4:00P<strong>M: </strong></b><span class="field-content"><a class="button_clear" href="http://www.eclipsecon.org/2013/node/1175"><strong>Getting Started With Xtend</strong></a></span>
<br />
<div class="views-field-field-presenters-uid">
<div class="field-content">
Monday is <i>Tutorial Day</i>. In the afternoon, <a href="http://blog.efftinge.de/2013/03/working-with-json-data-from-java.html" target="_blank">Sven</a> and I will give you a jump start with <a href="http://xtend-lang.org/" target="_blank">Xtend</a>, a new programming language which makes the day-to-day tasks of us Java developers a real pleasure. We listened to you and prepared some new and entertaining tasks where you get your hands on <i>Active Annotations</i> and some new, interesting puzzlers. To put a long story short: If you want to learn about the hot new programming language that is developed at Eclipse, come and join our <a href="http://www.eclipsecon.org/2013/sessions/getting-started-xtend" target="_blank">tutorial</a>. </div>
<div class="field-content">
<a href="http://www.eclipsecon.org/2013/users/22"></a></div>
</div>
<br />
<b>Wed 4:15PM - 4:50PM: </b><span class="field-content"><a class="button_clear" href="http://www.eclipsecon.org/2013/node/1147"><strong>Null-Safety on Steroids</strong></a></span><br />
I'm happy to tell you that the <a href="http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/news/eclipse-news-part2.html" target="_blank">annotation based null-ness analysis</a> of the Eclipse JDT is getting better and better. Since the recent milestones, they do <a href="http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M5a-201302041400/news/" target="_blank">include fields</a> into the analysis and allow to <a href="http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M4-201212140730/news/#JDT" target="_blank">inherit the null specification</a> from super types so the analysis results become much more reliable and easier to adopt. Nevertheless, the JDTs approach is sometimes still based on assumption which I consider ... how shall I put that ... not really pragmatic. In this session, I want to outline the pros and cons of the current state of null analysis in Eclipse. Furthermore, I will talk about other approaches to tackle the occasional NPE that each of us developers is familiar with. I want to discuss the implications of the different solutions and offer advise on how to deal with them.<br />
<br />
<b>Thu 11:00AM - 11:35AM: </b><span class="field-content"><a class="button_clear" href="http://www.eclipsecon.org/2013/node/1378"><strong>Xtext - More Best Practices</strong></a></span>
<br />
My third session at this year's EclipseCon is a follow-up talk to another one that I gave in Reston, last year. In this years edition of the <i><a href="http://xtext.org/" target="_blank">Xtext</a> - Best Practices</i>, I will focus on other topics, especially on the adoption of the <a href="http://www.eclipse.org/Xtext/documentation.html#xbaseExpressions" target="_blank">Xbase expressions</a>. If you want to learn more about those, I can also highly recommend <a href="http://koehnlein.blogspot.de/" target="_blank">Jan</a>'s talk on <span class="field-content"><a class="button_clear" href="http://www.eclipsecon.org/2013/node/1274">Java DSLs with Xtext</a></span> on Tuesday.<br />
<br />
Anyway, there are still some things to prepare and there is never enough time for polishing. Obviously there are a <a href="http://www.eclipsecon.org/2013/node/1189" target="_blank">lot</a> <a href="http://www.eclipsecon.org/2013/node/1138" target="_blank">more</a> <a href="http://www.eclipsecon.org/2013/node/1275" target="_blank">interesting</a> <a href="http://www.eclipsecon.org/2013/node/1251" target="_blank">sessions</a> scheduled than I can list here. I'm really looking forward to a great conference and an intense week packed with interesting discussions. See you in Boston!<br />
<strong></strong><strong></strong> <br />
<br />
<div class="grid-6" id="branding">
</div>
</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-89832146538023720792013-03-21T16:43:00.002+01:002013-03-22T18:38:38.399+01:00Pimp My Visitors<div dir="ltr" style="text-align: left;" trbidi="on">
One of the most <a href="http://www.eclipse.org/xtend/releasenotes_2_4.html#active_annotations" target="_blank">noteworthy features of Xtend 2.4</a> are the <i>Active Annotations</i>. They allow you to participate in the compile process of Xtend code to the Java source code. In fact, you implement some kind of a mini code generator and hook into the Xtend compiler - and all this via a lightweight library. And the IDE is fully aware of all the changes that you do to the generated Java artifacts. The astonishing about it, that this approach allows you to develop the annotation processor and the client code side by side.<br />
<br />
Are you facing a repetitive coding problem and want to automate that? Nothing could be simpler. Just annotate your class and implement an <i>Active Annotation</i> and you are good.<br />
<br />
Which brings me to <a href="http://en.wikipedia.org/wiki/Software_design_pattern" target="_blank">design patterns</a>. Those often require a lot of boiler plate code since these patterns describe a blue print on how several objects interact with each other to solve a specific problem. So they are quite useful but also verbose by definition. One of the most tedious examples is the visitor pattern. Since I actually like to use a visitor to handle heterogeneous data structures (you know, decoupling and externalized traversal can be quite convenient) I decided to write a small annotation that creates all the fluff around this pattern on the fly. <br />
<br />
In order to implement a visitor, I just have to annotate the root type in the hierarchy and all the accept methods as well as the base class of the visitor implementation are automatically unfolded. You don't even have to define the base class for the visitor itself. The following small example basically expands to the very same, verbose Java code as in the <a href="http://en.wikipedia.org/wiki/Visitor_pattern#Source" target="_blank">example on Wikipedia</a> .<br />
<br />
<script src="https://gist.github.com/szarnekow/5213798.js?file=CarElement.xtend"></script>
<script src="https://gist.github.com/szarnekow/5213798.js?file=Visitors.xtend"></script>
<br />
Especially amazing is the fact, that this allows to define different kinds of visitors easily. Your accept-method has to take additional arguments? Just list them in the prototype method signature. You want to return a result? Nothing's easier than that - simply declare a different return type. The base implementation for all concrete visitors is already known? Just add the method body to the prototype and it will be moved to the visitor itself. Have a look at the <a href="https://gist.github.com/szarnekow/5213798">complete example</a> to see how beautiful this approach is. If you want to learn more about Active Annotations, you may want to dive into the <a href="http://www.eclipse.org/xtend/documentation.html#activeAnnotations">documentation on xtend-lang.org</a> and <a href="http://www.eclipse.org/xtend/download.html">install Xtend</a> to get your hands dirty.</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com3tag:blogger.com,1999:blog-6255758224607466565.post-34376809622134249102013-01-21T07:30:00.000+01:002013-01-21T07:30:02.307+01:00Java Hacks - Changing Final Fields<div dir="ltr" style="text-align: left;" trbidi="on">
Changing final fields? Really? Which may sound crazy at a first glance may be helpful in order to implement mocks or fix-up libraries that don't expose the state that you really wanted them to expose. And after all there is not always a fork me button available. But really: Final fields? Yes, indeed. You shall never forget: <i>There is no spoon</i>.<br />
<br />
Let's consider the following data class <span style="font-family: "Courier New",Courier,monospace; font-size: x-small;">Person</span> that we want to hack.<br />
<script src="https://gist.github.com/4509688.js?file=Person.java"></script>
Once a person was instantiated, it is not possible to change the value of the field <span style="font-family: "Courier New",Courier,monospace; font-size: x-small;">name</span>, is it?<br />
<h4 style="text-align: left;">
Reflection To The Rescue</h4>
Fortunately - or unfortunately - Java allows to access fields reflectively, and if (ab)used wisely, it is possible to change their value, too - even for final fields. Key is the method <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html" target="_blank">Field</a>#<a href="http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible%28java.lang.reflect.AccessibleObject[],%20boolean%29" target="_blank">setAccessible</a></span></span>. It allows to circumvent visibility rules - which is step one - and interestingly it also implicitly allows change the value of instance fields reflectively, if they were marked as accessible. <br />
<script src="https://gist.github.com/4509688.js?file=MakeModifiable.java"></script>
<div style="text-align: left;">
Modifying static fields is a little trickier. Even if <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">#setAccessible</span></span> was invoked, the runtime virtual machine will throw an <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">IllegalAccessException</span></span> (which I would expect anyway) because one <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">'Can not set static final my.field.Type field'</span></span> even though that was perfectly ok for instance fields. And since there is still no spoon - there is a way out. And again it's based on reflection, but this one's a little trickier. If we don't just set the field accessible but also change its modifiers to non-final, it's ok to alter the value of the field. </div>
<script src="https://gist.github.com/4509688.js?file=ForceMakeModifiable.java"></script>
This hack will allow to change the value of static fields, too. That is, as long as they are not initialized with literals that will be inlined by the compiler. Those include number literals and string literals, which are compiled directly into the call site to save some computation cycles (yes, refering to String constants from other classes does not introduce a runtime dependency to those classes). Despite those cases, other common static field types like loggers or infamous singletons can be easily modified at runtime and even (re)set to <span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">null</span></span>.<br />
<br />
The complete code looks like this and as promised, it will print the new name of the person to the console and the changed default name, too.
<script src="https://gist.github.com/4509688.js?file=Doh.java"></script>
But keep in mind: Don't do this at home!</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com11Kiel, Germany54.3232927 10.12276520000000354.027092200000006 9.4773182000000027 54.6194932 10.768212200000004tag:blogger.com,1999:blog-6255758224607466565.post-2036238072943401222012-12-13T22:04:00.000+01:002012-12-13T22:04:06.683+01:00Fixed Checked Exceptions - The Xtend Way<div dir="ltr" style="text-align: left;" trbidi="on">
Recently I stumbled across a <a href="http://java8blog.com/post/37385501926/fixing-checked-exceptions-in-java-8" target="_blank">post about checked exceptions</a> in <a href="http://twitter.com/samberan" target="_blank">Sam Beran's</a> <a href="http://java8blog.com/" target="_blank">Java 8 blog</a>. What he basically described is a means to reduce the burden when dealing with legacy APIs that <strike>abused</strike> used Java's checked exceptions. His example is build around the construction of a <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">java.net.URI</span> </span>which may throw an <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">URISyntaxException</span></span>.<br />
<script src="https://gist.github.com/4279571.js?file=Java7.java"></script>
Actually the <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">URI</span></span> class is not too bad, since it already provides a static factory <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">URI#create(String) </span></span>that wraps the checked <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">URISyntaxException</span></span> in an <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">IllegalArgumentException</span></span>, but you get the idea.
<br />
<h4 style="text-align: left;">
An Attempt to Tackle Checked Exception</h4>
Now, that Java will finally get <a href="http://openjdk.java.net/projects/lambda/" target="_blank">lambda expressions</a> with JSR 335, Sam suggests to use some utility class in order to avoid littering your code with <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">try { .. } catch ()</span></span> statements. For example, <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">Throwables#propagate</span></span> could take care of that boilerplate:<br />
<script src="https://gist.github.com/4279571.js?file=Java8.java"></script>
Does that blend? I don't think so. That's still way too much code in order to deal with something that I cannot handle at all in the current context - and compared to the Java7 version, it's not much of an improvement either. The latter does not even carry the stacktrace so the actual code would more look like this:<br />
<script src="https://gist.github.com/4279571.js?file=Java8Again.java"></script>
According to the number of characters and taking into account that this snippet does not even tell the reader which sort of exception was expected, I would always go for the classic <span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">try { .. } catch ()</span></span>.
<br />
<h4 style="text-align: left;">
Or I'd Use Xtend.</h4>
<script src="https://gist.github.com/4279571.js?file=Xtend.xtend"></script>
<a href="http://xtend-lang.org/" target="_blank">Xtend</a> will transparently <a href="http://www.eclipse.org/xtend/documentation.html#declaredExceptions" target="_blank">throw the checked exception</a> if you don't care about it. However, if you want to catch and handle it, feel free to do so. For the <strike>common</strike> other cases, the Xtend compiler uses the <a href="http://projectlombok.org/features/SneakyThrows.html" target="_blank">sneaky throw</a> mechanism that is used in project Lombok, too. It just uses some generics magic to trick the Java compiler thus allowing to throw a checked exception without declaring it. You are free to catch that one whenever you want. There is no need to wrap it into some sort of <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">RuntimeException</span></span> just to convince the compiler that you know what you are doing.<br />
<br />
By the way: You could of course use something like <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">Throwables</span></span> with Xtend, too:<br />
<script src="https://gist.github.com/4279571.js?file=Throwables.xtend"></script>
<script src="https://gist.github.com/4279571.js?file=Client.xtend"></script>
That's what I consider fixing checked exceptions.</div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com2tag:blogger.com,1999:blog-6255758224607466565.post-608003016228580122012-11-27T10:36:00.001+01:002012-11-27T11:23:58.727+01:00Performance Is Not Obvious<div dir="ltr" style="text-align: left;" trbidi="on">
Recently there was a <a href="http://www.eclipse.org/forums/index.php/mv/msg/432854/983757/#msg_983757" target="_blank">post</a> in the Xtext forum about the runtime performance of a particular function in the Xtext code base:<br />
<br />
<script src="https://gist.github.com/4153356.js?file=Original.java"></script>
<br />
<a href="http://ed-merks.blogspot.de/">
Ed Merks</a> suggested to rewrite the method to a loop iteration instead of a recursive function and to save one invocation of the method <span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">eContainer</span></span> such as the new implementation shall become at "least twice as fast."<br />
<br />
<script src="https://gist.github.com/4153356.js?file=Rewritten.java"></script>
<br />
I really liked the new form since is much easier to debug and to read and from that point a the <a href="http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=5b5eeedcd55f9fdb78c9eef19f3e0c77a35af52e" target="_blank">change</a> is definitely worth it. However, as I recently did a deep dive into the runtime behavior of the JVM, I doubted that the change would have to much impact on the actual performance of that method. So I took the time and sketched a <a href="https://gist.github.com/4153356#file_benchmark.java">small caliper benchmark</a> in order to double check my intuition.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhz-Q8EhW_-4O7Ev9nQj1zV8eAeX4fAw7EHo1T0HNJUcAQHsIy1-d7OFJAqk7ZfhqMFAg8n7McYE2r-rYjAVT_pGaW_-eEU_BGg13DgQrQOIrdAZA8Cuwo7LLmL7x_jboWedJtyTK2GV6k/s1600/containerPerformance.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="340" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhz-Q8EhW_-4O7Ev9nQj1zV8eAeX4fAw7EHo1T0HNJUcAQHsIy1-d7OFJAqk7ZfhqMFAg8n7McYE2r-rYjAVT_pGaW_-eEU_BGg13DgQrQOIrdAZA8Cuwo7LLmL7x_jboWedJtyTK2GV6k/s400/containerPerformance.png" width="400" /></a></div>
<br />
As it <a href="http://microbenchmarks.appspot.com/run/Sebastian.Zarnekow@gmail.com/ContainerByTypeBenchmark/2080011" target="_blank">turns out</a>, the refactored variant is approximately 5 to 20% faster for the rare cases where a lot of objects have to be skipped before the result was found and takes the same time for the common case where the requested instance is found immediately. So it's not even close to the expected improvements. But what's the take-away?<br />
<br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="302" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14929115" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="352"> </iframe>
<br />
Before applying optimizations it's worthy to measure the impact. It may be intuitive to assume that cutting the number of method invocation down to a fraction of the original implementation - after all it was a recursive implementation before - saves a lot of time but actually the JVM is quite powerful and mature at inlining and producing optimized native code. So I can only repeat the conclusion of my <a href="http://www.eclipsecon.org/europe2012/sessions/java-performance-mythbuster" target="_blank">talk</a> about Java Performance (which I <a href="http://www.eclipsecon.org/2013/sessions/java-performance-mythbusters" target="_blank">proposed</a> for EclipseCon Boston, too):<br />
<ul style="text-align: left;">
<li>[..] Write Readable and Clear Code. [..] (David Keenan)</li>
<li>[..] slavishly follow a principle of simple, clear coding that avoids clever optimizations [..] (Caliper FAQ)</li>
<li>Performance advice has a short shelf-life (B. Goetz)</li>
</ul>
From that point of view, the refactored implementation is definitely worth it, even though there is no big impact on the runtime behavior of the method. </div>
Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com5tag:blogger.com,1999:blog-6255758224607466565.post-40520173028896231602012-11-14T14:30:00.000+01:002012-11-14T14:30:04.718+01:00Xtext Corner #9 - About Keywords, AgainIn the last weeks, I compiled some information about proper usage of keywords and generally about terminals in <a href="http://www.xtext.org/" target="_blank">Xtext</a>:<br />
<ul>
<li>Keywords may help to <a href="http://zarnekow.blogspot.de/2012/11/xtext-corner-7-parser-error-recovery.html" target="_blank">recover from parse errors</a> in a sense that they guide the parser.</li>
<li>It's recommended to use <a href="http://zarnekow.blogspot.de/2012/11/xtext-corner-8-libraries-are-key.html" target="_blank">libraries</a> instead of a hard wired keyword-ish representation for some built in language features.</li>
<li><a href="http://zarnekow.blogspot.de/2012/11/xtext-corner-6-data-types-terminals-why.html" target="_blank">Data type rules</a> are the way to go if you want to represent complex syntactical concepts as atomic values in the AST.</li>
</ul>
In addition to these hints, there is one particular issue that arises quite often in the Xtext forum. People often wonder why their grammar does not work properly for some input files but perfectly well for others. What it boils down to in many of these examples is this:<br />
<div style="text-align: center;">
<blockquote class="tr_bq">
<i>Spaces are evil!</i></blockquote>
</div>
This seems to be a bold statement but let me explain why I think that keywords should never contain space characters. I'm assuming you use the default terminals but actually this fits for almost all terminal rules that I've seen so far. There is usually a concept of an <span style="font-family: inherit;">ID</span> which is defined similar to this:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">terminal ID: </span><br />
<span style="font-family: "Courier New",Courier,monospace;"> ('a'..'z'|'A'..'Z') ('a'..'z'|'A'..'Z'|'0'..'9')*;</span><br />
<h4>
IDs and Keywords </h4>
IDs start with a character followed by an arbitrary number of additional characters or digits. And keywords usually look quite similar to an ID. No surprises so far. Now let's assume a keyword definition like <span style="font-family: "Courier New",Courier,monospace;">'some' 'input'</span> compared to <span style="font-family: "Courier New",Courier,monospace;">'some input'</span>. What happens if the lexer encounters an input sequence <span style="font-family: "Courier New",Courier,monospace;">'som '</span> is the following. It'll start to consume the leading <span style="font-family: "Courier New",Courier,monospace;">'s'</span> and has not yet decided which token to emit, since it could become a keyword or an identifier. Same for the <span style="font-family: "Courier New",Courier,monospace;">'o'</span> and the <span style="font-family: "Courier New",Courier,monospace;">'m'</span>. The trailing space is the character where it can finally decide that <span style="font-family: "Courier New",Courier,monospace;">'som '</span> contains two tokens: an identifier and a whitespace token. So far so good.<br />
<h4>
Let the Parser Fail - For Free </h4>
Now comes the tricky part since the user continues to type an <span style="font-family: "Courier New",Courier,monospace;">'e'</span> after the <span style="font-family: "Courier New",Courier,monospace;">'m'</span>: <span style="font-family: "Courier New",Courier,monospace;">'some '</span>. Again, the lexer starts with the <span style="font-family: "Courier New",Courier,monospace;">'s'</span> and continues to consume the <span style="font-family: "Courier New",Courier,monospace;">'o'</span>, <span style="font-family: "Courier New",Courier,monospace;">'m'</span> and <span style="font-family: "Courier New",Courier,monospace;">'e'</span>. No decision was made yet: it could still be an ID or the start of the keyword <span style="font-family: "Courier New",Courier,monospace;">'some input'</span>. The next character is a space, and that's the crucial part here: If grammar contains a keyword 'some input', the space is expected since it is part of the keyword. Now, the lexer has only one valid alternative. After the space it is keen on consuming an <span style="font-family: "Courier New",Courier,monospace;">'i'</span>, <span style="font-family: "Courier New",Courier,monospace;">'n'</span>, <span style="font-family: "Courier New",Courier,monospace;">'p'</span>, <span style="font-family: "Courier New",Courier,monospace;">'u'</span> and <span style="font-family: "Courier New",Courier,monospace;">'t'</span>. Unfortunately, there is no <span style="font-family: "Courier New",Courier,monospace;">'i'</span> in the parsed text since the lexer already reached the end of the file.<br />
<br />
As already mentioned in an earlier post, the lexer will never roll back to the token <span style="font-family: "Courier New",Courier,monospace;">'some'</span><span style="font-family: inherit;"> </span>in order to create an <span style="font-family: "Courier New",Courier,monospace;">ID</span> token and a subsequent whitespace. In fact the space character was expected as part of single token so it was safe to consume it. Instead of rolling back and creating two tokens, the lexer will emit an error token which cannot be handled by the parser. Even though the text appeared to be a perfectly valid ID followed by a whitespace, the parser will fail. That's why spaces in keywords are considered harmful.<br />
<br />
In contrast, the variant with two split keywords of the grammar works fine. Here, the user is free to apply all sorts of formatting to the two adjacent keywords, any number of spaces, line breaks or even comments can appear between them, are valid and handled well by the parser. If you are concerned about the convenience in the editor - after all, a single keyword with a space seems to be more user friendly in the content assistant - I recommend to tweak that one instead of using an error prone grammar definition.Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com14tag:blogger.com,1999:blog-6255758224607466565.post-31919641666616368332012-11-08T12:30:00.000+01:002012-11-08T12:30:05.871+01:00Xtext Corner #8 - Libraries Are KeyIn today's issue of the Xtext Corner, I want to discuss the library approach and compare it to some hard coded grammar bits and pieces. The question about which path to choose often arises if you want to implement an IDE for an existing language. Most languages use a run-time environment that exposes some implicit API.<br />
<br />
Just to name a few examples: Java includes the JDK with all its classes and the virtual machine has a notion of primitive types (as a bonus). JavaScript code usually has access to a DOM including its properties and functions. The DOM is provided by the run-time environment that executes the script. SQL in turn has built-in functions like <span style="font-family: "Courier New",Courier,monospace;">max</span>, <span style="font-family: "Courier New",Courier,monospace;">avg</span> or <span style="font-family: "Courier New",Courier,monospace;">sum</span>. All these things or more or less an integral part of the existing language.<br />
<br />
As soon as you start to work on an IDE for such a language, you may feel tempted to wire parts of the environment into the grammar. After all, keywords like <span style="font-family: "Courier New",Courier,monospace;">int</span>, <span style="font-family: "Courier New",Courier,monospace;">boolean</span> or <span style="font-family: "Courier New",Courier,monospace;">double</span> feel quite natural in a Java grammar - at least a first glance. In the long run it often turns out to be a bad idea to wire these things into the grammar definition. The alternative is to use a so called library approach: The information about the language run-time is encoded in an external model that is accessible to the language implementation.<br />
<h4>
An Example</h4>
To use again the Java example (and for the last time in this post): The ultimate goal is to treat types like <span style="font-family: "Courier New",Courier,monospace;">java.lang.Object</span> and <span style="font-family: "Courier New",Courier,monospace;">java.util.List</span> in the same way as <span style="font-family: "Courier New",Courier,monospace;">int</span> or <span style="font-family: "Courier New",Courier,monospace;">boolean</span>. Since we did this already for Java as <a href="http://www.eclipse.org/Xtext/documentation.html#jvmtypes" target="_blank">part of the Xtext core framework</a>, let's use a different, somehow artificial example in the following. Our dummy language supports function calls of which <span style="font-family: "Courier New",Courier,monospace;">max</span>, <span style="font-family: "Courier New",Courier,monospace;">min</span> and <span style="font-family: "Courier New",Courier,monospace;">avg</span> are implicitly available.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDOv6vd_EjXiEOkVFja4LTUnduZmWa4L7JRKyTL0eIL5WmhFAjBSlEycHrJLgnhpvaCkTM0GzqbmRl9zz7Q7NQyTNrcP9_x9iatupyJz7w2jDsTh5bO3yy1YuncPdaamjlAYVHT8ckNVg/s1600/max_min_avg.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="132" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDOv6vd_EjXiEOkVFja4LTUnduZmWa4L7JRKyTL0eIL5WmhFAjBSlEycHrJLgnhpvaCkTM0GzqbmRl9zz7Q7NQyTNrcP9_x9iatupyJz7w2jDsTh5bO3yy1YuncPdaamjlAYVHT8ckNVg/s320/max_min_avg.png" width="320" /></a></div>
The hard-coded approach looks quite simple at first. A simplified view on the things will lead to the conclusion that the parser will automatically check that the invoked functions actually exist, content assist works out of the box and even the coloring of keywords suggests that the three enumerated functions are somehow special.<br />
<br />
Not so obvious are the pain-points (which come for free): The documentation for these functions has to be hooked up manually, the complete signatures of them have to be hard-coded, too. The validation has to be aware of the parameters and return types in order to check the conformance with the actual arguments. Things become rather messy beyond the first quickly sketched grammar snippet. And last but not least there is no guarantee that the set of implicit functions is stable forever with each and every version of the run-time. If the language inventor introduces a new function <span style="font-family: "Courier New",Courier,monospace;">sum</span> in a subsequent release, everything has to be rebuild and deployed. And you can be sure that the to-be-introduced keyword <span style="font-family: "Courier New",Courier,monospace;">sum</span> will cause trouble at least in one of the existing files.<br />
<h4>
Libraries Instead of Keywords</h4>
The library approach seems to be more difficult at first but it pays off quickly. Instead of using hard-coded function names, the grammar uses only a cross reference to the actual function. The function itself is modeled in another resource that is also deployed with the language.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgo7JQr_KmKvOy6xMkKyF3l5k3E2-6Zzm3-AOu-FARWRJ1OgJpwZxO2D57DYgRmAbimw7Bi06IiNg42vMzUrs3ICqdO7vv2xCLL9khh2HIKU2eAPyc5bgOrvrbazr5EwvAyRAiHq6ovACw/s1600/function_call.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="152" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgo7JQr_KmKvOy6xMkKyF3l5k3E2-6Zzm3-AOu-FARWRJ1OgJpwZxO2D57DYgRmAbimw7Bi06IiNg42vMzUrs3ICqdO7vv2xCLL9khh2HIKU2eAPyc5bgOrvrbazr5EwvAyRAiHq6ovACw/s320/function_call.png" width="320" /></a></div>
This external definition of the built-in functions can usually follow the same guidelines as custom functions do. But of course they may even use a simpler representation. Such a stub may only define the signature and some documentation comment but not the actual implementation body. It's actualy pretty similar to header files. As long as there is no existing format that can be used transparently, it's often the easiest way to define an Xtext language for a custom stub format. The API description should use the same EPackage as the full implementation of the language. This ensures that the built-ins and the custom functions follow the same rules and all the utilities like the type checker and documentation provider can be used independently from the concrete invoked function.<br />
<br />
If there is an existing specification of the implicit features available, that one should be used instead. Creating a model from an existing, processable format is straight forward and it avoids mistakes because there is no redundant declaration of the very same information. In both cases there is a clear separation of concerns: The grammar remains what it should be: a description of the concrete syntax and not something that is tight to the run-time. The API specification is concise and easy to grasp, too. And in case an existing format can be used for that purpose, it's likely that the language users are already familiar with that format. <br />
<h4>
Wrap Up</h4>
You should always consider to use external descriptions or header stubs of the environment. A grammar that is tightly coupled to a particular version or API is quite error-prone and fragile. Any evolution of the run-time will lead to grammar changes which will in turn lead to broken existing models (that's a promise). Last but not least, the effort for a seamless integration of built-in and custom functions for the end-user exceeds the efforts for a clean separation of concerns by far.<br />
<br />
A very sophisticated implementation of this approach, can be explored in the <a href="https://github.com/cloudsmith/geppetto" target="_blank">Geppetto</a>
repository at GitHub. Geppetto uses puppet files and ruby libraries as
the target platform, parses them and puts them onto the scope of the
project files. This example underlines another advantage of the library
approach: It is possible to use a configurable environment. The APIs may
be different from version to version and the concrete variant can be
chosen by the user. This would never be possible with a hard-wired set
of built-ins.<br />
<br />Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com18tag:blogger.com,1999:blog-6255758224607466565.post-47306174027318657682012-11-06T12:30:00.000+01:002012-11-06T12:30:05.051+01:00Xtext Corner #7 - Parser Error RecoveryA crucial feature of the parser in <a href="http://www.xtext.org/" target="_blank">Xtext</a> is the ability to recover from errors: The parser may not fail on the first erroneous token in an invalid input but should continue after that token. In fact it should continue to the end of the document and yield an AST that is incomplete but contains as many nodes as possible. This feature of the parser is called error recovery: The ability to consume input text that is not conform to the grammar.<br />
<br />
Error recovery is obviously necessary in an interactive environment like an editor since most of the time the input will actually be invalid. As soon as the user starts to type, the document may be broken in all sorts of ways. The user does not really care whether his actions are in line with some internal AST-structure or grammar rules. Copy and paste, duplicate lines, remove portions of the file by using toggle comment or just plain insertion of characters into the editor - none of these operations should cause the parser to fail utterly. After all, content assist, the outline and code navigation are expected to work for broken documents, too - at least to some extend. <br />
<h4>
Recovery strategies </h4>
The Antlr parser that is generated from an Xtext grammar supports different recovery strategies. If the parser encounters an invalid input, it'll basically perform one of the following operations:<br />
<ol>
<li><i>Skip the invalid terminal symbol</i><br />If the current token is unexpected, the following terminal is considered. If that one matches the current expectation, the invalid token is skipped and flagged with an error.</li>
<li><i>Inject the missing token</i><br />The seen terminal is not valid at the current position in the parsing process but would be expected as the subsequent token. In that case, the parser might inject the missing token. It skips the current expectation and continues with the next step in the parsing. The information about the missing token is annotated on the current input symbol.</li>
<li><i>Pop the parsing stack</i><br />If the input is broken in a way that does not allow the parser to skip or inject a single token, it'll start to consume the following terminal symbols until it sees a token that is somehow unique in the expectation according to the current parsing stack. The parser will pop the stack and do a re-spawn on that element. This may happen in the rare case that the input is almost completely messed up.</li>
<li><i>Fail</i><br />The mentioned recovery strategies may fail due to the structure of the grammar or the concrete error situation in the input. In that case parsing will be aborted. No AST for subsequent input in the document will be produced.</li>
</ol>
<h4>
Helping the Parser</h4>
There exist several things that you should watch out for if you experience poor error recovery in your language. First and foremost it may be the absence of keywords in the grammar. Keywords are often the only anchor that the parser can use to identify proper recovery points. If you feel tempted to write an overly smart grammar without any keywords because it should look and feel like natural language, you should really reconsider your approach. Even though I don't want to encourage a keyword-hell, keywords are somehow convenient if they are used properly. And please note that things like curly braces, parentheses or other symbols with only one character are as good as a keywords as other, longer sequences - at least from the parsers perspective. So to give a very popular example: Instead of using indentation to describe the structure of your language (similar to Python), using a c-style notations may save you a lot of effort with the grammar itself and provide a better user experience when editing code. And keywords also serve as a nice visual anchor in an editor so users will have an easier time when reading code in your language. <br />
<br />
A second strategy to improve the behavior of the parser and the chance for nice error recovery is the auto-edit feature. It may have some flaws but it's quite essential for a good user experience. The most important aspect here is the insertion of closing quotes for strings and comments. As soon as you have an input sequence that is not only broken for the parser but lets even the lexer choke, you are basically screwed. Therefore multiline comments and strings are automatically closed as soon as you open them. If you use custom terminal rules, you should really consider to look for unmatched characters that should be inserted in pairs according to the lexer definition. The rule basically applies for paired parentheses, too. Even though the concrete auto-edit features may still need some fine tuning to not get in the way of the user, they already greatly improve the error recovery of the parser.Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com1tag:blogger.com,1999:blog-6255758224607466565.post-2091729186301406712012-11-02T12:30:00.000+01:002012-11-02T12:30:04.442+01:00Xtext Corner #6 - Data Types, Terminals, Why Should I Care?Issue #6 of the Xtext Corner is about some particularities of the parsing process in <a href="http://www.xtext.org/" target="_blank">Xtext</a>. As I already mentioned a few times in the past, Xtext uses <a href="http://www.antlr.org/" target="_blank">Antlr</a> under the hood in order to do the pure parsing. This is basically a two step process: At first, the input sequence of characters is split into tokens (often referred to as terminals) by a component that is called the lexer. The second step is to process the resulting list of tokens. The actual parser is responsible for that stage. It will create the abstract syntax tree from the token stream.<br />
<br />
This divide-and-conquer approach is mostly called parsing altogether so the distinction between lexing and parsing is quite encapsulated. Nevertheless, the Xtext grammar definition honors both aspects: It is possible to define (parser) rules that are processed by the parser and it is also possible to define terminal rules. Those will be handled in the lexer. So the when should I use parser rules and when should I use terminal rules?<br />
<h4>
Production Rules <i><span style="font-weight: normal;"><span style="color: #999999;">also: Parser Rules</span></span></i></h4>
The obvious case and just for the sake of completeness: Production rules will yield an instance in the abstract syntax tree. These can only be implemented by the parser thus there is no question whether to use terminals instead. Production rules are the most common rules in almost every Xtext grammar.<br />
<h4>
Data Type Rules</h4>
Those are a completely different thing even though they are handled by the parser, too: Where ordinary parser rules produce instances of EClasses, data type rules will return data types (you did not guess that, did you?). Data types in the sense of Xtext and its usage of the Eclipse Modeling Framework are basically primitive Java types, Strings or other commons like BigDecimal or enums. The parser will not create those on its own but rather pass the consumed tokens as a string to a <a href="http://www.eclipse.org/Xtext/documentation.html#valueconverter" target="_blank">value converter</a>. The language developer is responsible for converting the string to a data type.<br />
<h4>
Terminal Rules</h4>
Terminal rules are essentially the same as data type rules when you only consider the interface to the grammar. Internally they are completely different since they will not be processed by the parser but by the lexer. The consequences are quite severe if you want to get a working grammar. But one step after the other: As already mentioned, terminal rules can return the very same things as data type rules can. That is, they yield Strings, ints or other primitives. But since they are handled by the lexer, they are not quite as powerful as data type rules are. <br />
<h4>
Implementation aspects </h4>
The lexer is a pretty dumb component which is generated in a way that weights performance over intuitive behavior. Where the parser generator will produce nice error messages in case of ambiguous data types rules, conflicting terminals are mostly resolved by a first-come-first-served (FCFS, also <a href="http://en.wikipedia.org/wiki/First-in,_first-out" target="_blank">FIFO</a>) principle. For terminals it's crucial to get them in the right order. Consider the following terminal rules:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">terminal ID: ('a'..'z') ('a'..'z'|'0'..'9')*;</span><br />
<span style="font-family: "Courier New",Courier,monospace;">terminal CHARS: ('a'..'z'|'_')+;</span></blockquote>
The ID rule shall consume something that starts with a lowercase letter and is followed by a letter or number. The CHARS rule is pretty close to that one: It shall match a sequence that contains only lowercase letters or underscores. The problem with these is that the matched sequences are not mutually exclusive. If you take the input <span style="font-family: "Courier New",Courier,monospace;">abc</span> as an example, it will be matched as an ID given the two rules above. As soon as you switch the order of the declarations, the sequence <span style="font-family: "Courier New",Courier,monospace;">abc</span> will out of a sudden be returned as CHARS. That's one thing that you have to be a aware of if you use terminal rules. But there is more to keep in mind. <br />
<br />
Terminal rules are applied without any contextual information which has some interesting implications. The plus: it's easily possible to use the lexer on partial input - entry points can be computed almost trivially. There is no such thing as an entry rule as for the parser. But the disadvantages have to be taken into account, too. The lexer does not care about the characters that are still to come in the input sequence. Everything that matches will be consumed. And not reverted (as of Antlr 3.2). To explain what that means, let's take another example:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">terminal DECIMAL: INT '.' INT;</span><br />
<span style="font-family: "Courier New",Courier,monospace;">terminal INT: '0'..'9'+;</span></blockquote>
The rules define decimal numbers in a hypothetical language that also supports method invocation. At a first glance, things seem to work fine: <span style="font-family: "Courier New",Courier,monospace;">123</span> is consumed as an INT where <span style="font-family: "Courier New",Courier,monospace;">123.456</span> will be a decimal. But the devil's in the details. Let's try to parse the string <span style="font-family: "Courier New",Courier,monospace;">123.toString()</span>. The lexer will find an INT 123 - so far, so good. Now it sees a dot which is expected by the terminal rule DECIMAL. The lexer will consume the dot and try to read an INT afterwards - which is not present. Now it'll simply fail for the DECIMAL rule but never revert that dot character which was consumed almost by accident. The lexer will create an invalid token sequence for the parser and the method call cannot be read successfully. That's because the lexer simply does not know about things like the expectation in the current parser state. Attempts to define decimals, qualified names or other more complex strings like dates are very error prone and can often be implemented quite easy by means of data type rules:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">DECIMAL: INT '.' INT;</span><br />
<span style="font-family: "Courier New",Courier,monospace;">terminal INT: '0'..'9'+;</span></blockquote>
<h4>
Terminals Considered Harmful?</h4>
Data type rules move the decision from the <strike>dumb</strike> highly optimized lexer to the parser which has a lot more information at hand (the so called look ahead) to make decisions. So why not use data types everywhere? The simple answer is: performance. The duo of lexer and parser is optimized for a stream of reasonable sized tokens instead of hundreds of single characters. Things will not work out that well with Antlr at run-time if the parser is implemented in a so called scanner-less manner. The rule of thumb here is to use only a few number of terminal rules that can be distinguished easily and put data type rules on top of those. It'll simplify your live as a language developer tremendously.<br />Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com5tag:blogger.com,1999:blog-6255758224607466565.post-21538419594661939902012-11-01T22:40:00.003+01:002012-11-01T22:40:47.070+01:00JUGFFM: A Scenic View, Ebblewoi and Very Nice PeopleYesterday I had the opportunity to give a presentation about <a href="http://xtend-lang.org/" target="_blank">Xtend</a> at the JUG Frankfurt. I really enjoyed it since the audience had a lot of very good questions and quite some interesting discussion unfolded from those during the talk and thereafter. Many thanks to <a href="https://www.xing.com/profile/Alexander_Culum" target="_blank">Alex </a>who organized the event.<br />
<br />
<div align="center">
<iframe align="middle" frameborder="0" height="303" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14640521?hostedIn=slideshare&page=upload" width="360"></iframe></div>
<br />
The <a href="https://sites.google.com/site/jugffm/" target="_blank">JUGF Stammtisch</a> took place in the <a href="http://www.dnb.de/EN/Home/home_node.html" target="_blank">German National Library</a> which is such an amazing location. We were in a room on the upper floor and the nightly view on the skyline of Frankfurt was almost paralyzing - I even forgot to take a picture... For the informal Stammtisch after the talk we changed location to a secret Franconian Apfelwein Schenke whose coordinates may not be disclosed. According to the locals, it's one of the last resorts in Frankfurt that's still rather free from tourists (except for the Kieler guy who will probably never manage to pronounce <a href="http://www.hessischpedia.de/wiki/Ebbelwoi" target="_blank">Ebblewoi</a> correctly).<br />
<blockquote class="twitter-tweet tw-align-center">
Dank an @<a href="https://twitter.com/szarnekow">szarnekow</a> für den interessanten Xtend-Vortrag bei der @<a href="https://twitter.com/jugffm">jugffm</a>. Laßt euch das Apfelkompott schmecken... ;-)<br />
— Hameister (@Hameiste) <a data-datetime="2012-10-31T19:48:47+00:00" href="https://twitter.com/Hameiste/status/263729248123121665">October 31, 2012</a></blockquote>
<br />
In the pub, the discussions continued over cutlet with traditional <a href="http://en.wikipedia.org/wiki/Green_sauce" target="_blank">Green Sauce</a>, typical Franconian cider or beer, since only Hessian stomachs can handle proper amounts of Ebblewoi. Unfortunately I had to leave at 10pm since I had to catch the receptionist in the hotel (thanks for the short briefing before I left, Apple maps indeed tried to play tricks on me...).<br />
<br />
To put a long story short: The JUGF is a really nice crowd and I enjoyed the company a lot. Their next meeting is already on 07 Nov 2012. If you are in Frankfurt next week, make sure to stop by if you want to discuss <a href="https://sites.google.com/site/jugffm/home/07-11-2012-mit-devops-krusten-aufbrechen-und-durchlaufzeiten-minimieren" target="_blank">DevOps topics</a>.
<script charset="utf-8" src="//platform.twitter.com/widgets.js"></script>Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-5851229272961978342012-10-31T11:00:00.000+01:002012-10-31T11:00:07.963+01:00Xtext Corner #5 - Backtracking vs Syntactic PredicatesThe Xtext grammar language allows to create a working parser in almost no-time. Its concise notation to describe the concrete syntax and the mapping to an object model is giving quite a jump start if you want to create a language. Nevertheless it's also quite easy to get into some trouble. Xtext uses Antlr 3.2 as the underlying parser technology and we try really hard to hide the complexity and peculiarity of Antlr. Unfortunately that's not possible in all cases. From time to time Antlr will report ambiguities in the grammar definition with a charming message like this:<br />
<blockquote class="tr_bq">
<span style="color: red; font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">warning(200): Decision can match input such as "{EOF, RULE_ID, '('}" using multiple alternatives: 1, 2<br />As a result, alternative(s) 2 were disabled for that input</span></span></blockquote>
The parse generator basically complains about an ambiguous grammar. At some point in the syntax description it cannot decide which path to follow for a given input sequence. It's rather obvious that the warning message is not really helpful. Neither is there any chance to find the correct line that caused the error (which is not a problem of Antlr but cause by the translation of Xtext to Antlr) nor is it easily possible to spot the concrete decision that the parser generator complains about. The worst about this is that it's not really a warning either. What the parser generator basically did is the following: It removed a possible path from the grammar description. It will always choose the one remaining path for that particular situation. Which could by chance be the one that you'd expect. But it could also be the wrong path.<br />
<h4>
AntlrWorks</h4>
Fortunately there is a tool that helps to identify the problem: <a href="http://www.antlr.org/works/index.html" target="_blank">AntlrWorks </a>allows to take a look at the grammar and visualize all the problems that it has graphically. It's still far from trivial to find the root cause of a problem but better than nothing. Make sure you pick the version 3.2 from <a href="http://www.antlr.org/download" target="_blank">download section</a> if you want to give it a try.<br />
<br />
Now you may wonder how you should handle the cases that are ambiguous by definition and by intention. You could of course enable backtracking in your language and afterwards everything appears to be fine. However, you can think about backtracking as a wildcard for Antlr to remove alternatives from your grammar everywhere where it spots an ambiguity. This will shadow the real problems in the grammar that may be introduced due to subsequent changes, a refactoring or new language features. That's why I strongly recommend to go for the hard way and analyze the root cause for the warnings. As soon as you found the actual decision that the parser generator complained about, you can use a <a href="http://www.eclipse.org/Xtext/documentation.html#antlr_errors" target="_blank">syntactic predicate</a> to fix that locally. Now you are in control on which alternative to remove and which path to follow. I think that makes perfect sense to be in charge in those cases.<br />
<h4>
Backtracking </h4>
But the shadowing of errors in the generator is only one drawback of backtracking. It will furthermore lead to surprising messages at run-time. If you consider the following snippet it's easy to see that the right operand of the binary operation is missing.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik-HpTrQDVhoLNC6eXswxsQmIKJ1bv4fXuIJvxcb2EK3CKNZDQ3rkyq5t9zLiQjVSZ4jgdlrvQ6tqOvZ_-JBF7iZqoYliUpWU1VnhI9-mpHsVdOEWUOQc7_RqVYsE1l7R6U-jfovYmyhE/s1600/strange_error.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="52" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik-HpTrQDVhoLNC6eXswxsQmIKJ1bv4fXuIJvxcb2EK3CKNZDQ3rkyq5t9zLiQjVSZ4jgdlrvQ6tqOvZ_-JBF7iZqoYliUpWU1VnhI9-mpHsVdOEWUOQc7_RqVYsE1l7R6U-jfovYmyhE/s200/strange_error.png" width="200" /></a></div>
The parser will correctly report something along the lines of<br />
<blockquote class="tr_bq">
<span style="font-size: x-small;"><span style="color: red;"><span style="font-family: "Courier New",Courier,monospace;">mismatched input '}' expecting RULE_INT</span></span></span></blockquote>
Unfortunately it does so on a totally unexpected location. If you enabled backtracking and the algorithm decides that the function declaration is not complete - it fails to read a valid function body - the parsing will roll back to the start of the function and put the most specific error message on that token. You'll see an error marker under the keyword <span style="font-family: "Courier New",Courier,monospace;">function</span>. However, it would be more intuitive to have that error on the binary operation. At least that's what I would expect, wouldn't you?<br />
<h4>
Syntactic Predicates</h4>
Nevertheless it's not always possible to write an unambiguous grammar. There are some common patterns that are undecidable by definition. The most famous one is the <a href="http://en.wikipedia.org/wiki/Dangling_else" target="_blank">Dangling else</a>. If a language allows nested <i>if-else</i> constructs, it's not definite where a subsequent else keyword may belong to. Consider the following Java snippets which only differ in formatting:<br />
<br />
<script src="https://gist.github.com/3965194.js?file=Sample.java"></script>
The semantics of both code snippets should be independent from the formatting. Nevertheless it's ambiguous for the parser in the same way as a reader might be confused by an inconsistent indentation. Therefore you have to force the parser into one concrete direction in order to disambiguate the grammar. A syntactic predicate has to be added.<br />
<br />
<script src="https://gist.github.com/3965194.js?file=gistfile1.java"></script>
The <span style="font-family: "Courier New",Courier,monospace;">=></span> operator forces the parser to go a certain path if the input sequence would allow two or more possible decisions. It can be read as <i>If you see these tokens, go this way</i>. It's even possible to use alternatives or groups of elements as the criteria. Only the UnorderedGroup is prohibited in predicates.<br />
<br />
<script src="https://gist.github.com/3965231.js?file=gistfile1.java"></script>
In this example, the parser shall follow the given path if it can look ahead to a sequence like <span style="font-family: "Courier New",Courier,monospace;">person.name=</span> (or more abstract <span style="font-family: "Courier New",Courier,monospace;">ID . ID =</span>).<br />
<h4>
Implementation Detail</h4>
One thing is important to note. Syntactic predicates in Xtext are different from the plain Antlr predicates. In the Xtext grammar language it's only possible to use a complete or a partial sequence of production tokens as the predicate where Antlr allows to use arbitrary tokens that seem to be independent from the actual rule content. Here Antlrs approach appears to be more powerful. But actually that's only at a first glance. Firstly Xtext's variant is easier to use since you don't have to repeat parts of your grammar manually. And secondly it's the framework that does the heavy lifting: The syntactic predicates in Xtext are automatically propagated to the right places which you'd have to do manually otherwise. Just insert it at the spot that you identified with AntlrWorks and you're done.Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com3tag:blogger.com,1999:blog-6255758224607466565.post-52686932069833179972012-10-29T13:30:00.000+01:002012-10-29T13:30:04.328+01:00Xtext Corner RevivedIt's been a long time since I wrote about <a href="http://www.xtext.org/" target="_blank">Xtext</a> tips and tricks. However, I assembled a bunch of interesting tips and tricks while I prepared my <a href="http://www.eclipsecon.org/europe2012/sessions/xtext-best-practices" target="_blank">Xtext Best Practices</a> session for this years EclipseCon which I want to share with you.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe align="middle" frameborder="0" height="303" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14904879" width="360"></iframe></div>
<br />
<br />
The talk starts with a short overview on how I personally like to tackle the task of implementing a language with Xtext. If the syntax is not yet carved in stone, I usually start of with some sketched sample files to get an idea about the different use cases. In doing so it's quite important to find a concise notation for the more common cases and to be more verbose with the unusual patterns that are anticipated in the language. As soon as the first version of the syntax is settled, it's obvious to begin with the grammar declaration.
<br />
<br />
That's a task that I really like. The grammar language of Xtext is probably the most concise and information rich DSL that I ever worked with. With very few orthogonal concepts it's possible to describe how a text is parsed and in the very same breath map those parsed information to a in memory representation. This representation is called abstract syntax tree (AST) and often referred to as model. The AST that Xtext yields is strongly typed and therefore heterogeneous, but still provides generic traversal possibilities since it is based on the Eclipse Modeling Framework (EMF, also: Ed Merks Framework). So the grammar is about the concrete syntax and its mapping to the abstract syntax.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuCAs8fZDrV6uZFqvfQgl42R6qhQHSaPb-1-_4PMsW2G9tCp9MLQfEkVW8e0C825fReM5DwwKCpceMYLSRRPhds47If-xKxMa1jUuY_AwS0wCa7tSCfzQ3cZ2NNm65nDw_cr8AXwZWi2E/s1600/anatomy.002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuCAs8fZDrV6uZFqvfQgl42R6qhQHSaPb-1-_4PMsW2G9tCp9MLQfEkVW8e0C825fReM5DwwKCpceMYLSRRPhds47If-xKxMa1jUuY_AwS0wCa7tSCfzQ3cZ2NNm65nDw_cr8AXwZWi2E/s320/anatomy.002.png" width="320" /></a></div>
<br />
As soon as the result of the parsing is satisfying, the next step when implementing a language is scoping. Without that one, any subsequent implementation efforts are quite a waste of effort. Scoping is the utility that helps to enrich the information in the AST by creating a graph of objects (Abstract Syntax Graph, ASG). This process is often called cross linking. Thereby some nodes in the tree will be linked with others that are not directly related to them in the first place. This is one of the most important aspects of a language implementation because after the linking and scoping was done, the model is actually far more powerful from a clients perspective. Any code that is written on top of that can leverage and traverse the complete graph even if the concrete language is split across many files.<br />
<br />
Validation is the next step and it is implemented on top of the linked ASG. While the parser and the linking algorithm already produced some error annotations on invalid input sequences, it's the static constraint checking which will find the remaining semantic problems in the input. If the files were parsed and linked successfully and the static analysis does not reveal any problems, the model can be considered valid.<br />
<br />
Now that one can be sure that the ASG as the in-memory representation of the files fulfills the semantic constraints of the language, it's possible to implement the execution layer which is often a compiler, a code generator or an interpreter. Actually those three are all very similar. You can think of a code generator as an interpreter which evaluates a model to a string. And of course a compiler is pretty much the same as a code generator but the output is not plain text but some sequence of bytes. The important thing is that the evaluation layer should (at least in the beginning) only consider valid input models. This will dramatically simplify the implementation and that's the reason why I like to implement that on top of a checked ASG. You don't have to take all those possible violated constraints into account.<br />
<br />
Now there is of course still the huge field of the user interface that entwines around the editor and its services like content assist, navigation or syntax coloring. However, I would usually postpone that until the language runtime works at least to some extend.<br />
<br />
The most important message in this intro is that this is not a waterfall process. All this can be implemented in small iterations each of which is accompanied with refined sample models, unit tests (!) and feedback from potential users.<br />
<br />
In the next days I'll wrap up some of the main points of my presentation
which will be about grammar tips, some hints on scoping, validation or
content assist. Stay tuned for those!Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com5Kiel, Germany54.3232927 10.122765254.175124200000006 9.8069082 54.4714612 10.4386222tag:blogger.com,1999:blog-6255758224607466565.post-90821185793386786192012-10-29T10:50:00.000+01:002012-10-29T10:53:19.906+01:00EclipseCon 2013, Proposal Submitted? Check!As the early bird submission deadline for the <a href="http://www.eclipsecon.org/2013/" target="_blank">EclipseCon 2013</a> in North America is approaching, I took the time and proposed a session that I had quite some fun with in Ludwigsburg. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9Uveqkiu-U6rK0erq0ehw_AxqIr4cHoc-j0RTVn1Okeaib3c_QlwPxzZlhc4KhN8S_WTheDrd65EsYqivjwMy-dlFtcxGUkB0lihcQXhK0K0Me8ydi1HoIoTjZS41JxYoQ3rm39lB-3w/s1600/010A8C8A-0BD9-4040-95F9-1E7BD1A4BF77.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9Uveqkiu-U6rK0erq0ehw_AxqIr4cHoc-j0RTVn1Okeaib3c_QlwPxzZlhc4KhN8S_WTheDrd65EsYqivjwMy-dlFtcxGUkB0lihcQXhK0K0Me8ydi1HoIoTjZS41JxYoQ3rm39lB-3w/s200/010A8C8A-0BD9-4040-95F9-1E7BD1A4BF77.JPG" width="200" /></a></div>
The overwhelming interest in my talk about <a href="http://www.eclipsecon.org/europe2012/sessions/java-performance-mythbuster" target="_blank">Java Performance MythBusters</a> motivated me to propose round 2. I expect that the time until next years EclipseCon will bring some new insights and refined numbers, too.<br />
<br />
After all, Java8 is currently under heavy development and so it's quite likely that the measured times and numbers will change dramatically. And of course it will be interesting to take a look at the performance characteristics of other platforms, e.g. Linux and Windows.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="302" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14929115" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="352"> </iframe>
</div>
<br />
Which topics would you be interested in? Run-time cost of reflective access? Arrays vs collections? Auto-boxing? There are still plenty of myths out there and I will again pick some of them to go for the next round. Let's put them on the test-bet!Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-59763757736055792922012-10-29T08:30:00.000+01:002012-10-29T08:30:00.610+01:00Xtend @ JUGFIn Frankfurt and no plans for Wednesday evening? How about joining the <a href="https://sites.google.com/site/jugffm/home/term/31-10-2012-xtend---eine-sprache-von-java-entwicklern-fuer-java-entwickler" target="_blank">JUGF-Stammtisch</a> on 31 Oct 2012 at 18:30 in the <a href="http://www.d-nb.de/" target="_blank">German National Library</a>. I will be there and give a talk about <a href="http://www.xtend-lang.org/" target="_blank">Xtend</a> featuring a preview of the upcoming language feature called <a href="http://blog.efftinge.de/2012/10/introducing-active-annotations.html" target="_blank">Active Annotations</a>. If you are interested in the latest news on Xtend, make sure you <a href="http://doodle.com/z34i4wk5dc3gbzug" target="_blank">register</a> for the session and attend the Stammtisch. See you there!Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-35927578616260991102012-10-26T16:58:00.001+02:002012-10-26T16:58:27.925+02:00EclipseCon Europe 2012 - Wrap-UpAs <a href="http://zarnekow.blogspot.de/2012/10/eclipsecon-europe-join-party.html" target="_blank">promised</a>, this years <a href="http://www.eclipsecon.org/europe2012/" target="_blank">EclipseCon Europe</a> again was a great community event with astonishing technical content, outstanding food and most importantly many good friends. The conference organizers did a great job and prepared something for everybody: there were autonomously flying <a href="http://www.flickr.com/photos/33725200@N00/8118976707/in/pool-2115384@N23" target="_blank">robots</a>, a circus with do-it-yourself <a href="http://www.flickr.com/photos/33725200@N00/8118609924/in/pool-2115384@N23" target="_blank">fire breathing</a> and a great live band. It's this package which makes the EclipseCon a unique and memorable experience. And the co-located <a href="http://www.flickr.com/photos/33725200@N00/8114427805/in/photostream/" target="_blank">beerfest at the Nestor Bar</a> did its share to ensure that we don't get too much sleep.<br />
<br />
However, as Sepp Herberger put it: "After the game is before the game!" The next EclipseCon will be in <a href="http://www.eclipsecon.org/2013/" target="_blank">Boston, 25 - 28 March</a>. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.eclipsecon.org/2013/sites/all/themes/econ2013/logo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.eclipsecon.org/2013/sites/all/themes/econ2013/logo.png" /></a></div>
<br />
The <a href="http://www.eclipsecon.org/2013/early-talk-selection" target="_blank">early bird deadline</a>
for the call for papers is the 31 Oct. Don't hesitate and submit
your proposals about the things that you want to share with others! The more the merrier!<br />
<br />
There will also be an EclipseCon in France, on 5-6 June for the first time. After the great success of this years EclipseDay in Toulouse, the foundation will organize a two day conference there in the next year! Stay tuned for the call for papers.<br />
<br />
And of course you should safe the date for next years ECE in Ludwigsburg from 29-31 Oct.
<br />
<br />
In the meantime make sure you don't forget to complete the <a href="http://www.surveymonkey.com/s/ece2012" target="_blank">conference survey</a> and provide feedback for the speakers.Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-4374055079675872702012-10-16T15:16:00.001+02:002012-10-16T15:16:57.189+02:00EclipseCon Europe - Join the Party!Only one week until <a href="http://www.eclipsecon.org/europe2012/" target="_blank">EclipseCon Europe 2012</a> will take off in <a href="http://www.ludwigsburg.de/,Len/Home.html" target="_blank">Ludwigsburg</a>. Again hundreds of Eclipse enthusiasts will strive for the next record of highest WiFi usage <i>ever</i> in the Swabian city with the largest <a href="http://en.wikipedia.org/wiki/Ludwigsburg_Palace" target="_blank">baroque castle</a> in Germany. From Oct 23 to 25 the Forum am Schlosspark will transform to a vibrant place of technical discussions, entertaining sessions and socializing. Thanks to the huge amount of submissions from the Community the <a href="http://www.eclipsecon.org/europe2012/call-papers-coming-soon" target="_blank">program committee</a> managed again to tie up three days of deep technical content about Eclipse, the framework and the ecosystem, about its past, present and future (actually not to much about the past, but that's a good thing, isn't it?).<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.eclipsecon.org/europe2012/sites/eclipsecon.org.europe2012/files/europe2012_logo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.eclipsecon.org/europe2012/sites/eclipsecon.org.europe2012/files/europe2012_logo.jpg" /></a></div>
<br />
I will have the pleasure to talk about a potpourri of different topics that each cover some field of interest of mine.<br />
<br />
<b>Tue 9:00AM - 12:30PM: <a href="http://www.eclipsecon.org/europe2012/sessions/getting-started-xtend" target="_blank">Getting Started With Xtend</a></b><br />
My conference starts on Tuesday Morning at 9:00 in the Schubartsaal. <a href="http://blog.efftinge.de/" target="_blank">Sven </a>and I give a tutorial about <a href="http://xtend-lang.org/" target="_blank">Xtend</a>
where you will have the chance to get your hands dirty on interesting
and challenging programming problems and puzzlers. You should not miss
that one!<br />
<br />
<b>Wed 2:00PM - 2:30PM: <a href="http://www.eclipsecon.org/europe2012/sessions/xtext-best-practices" target="_blank">Xtext - Best Practices</a></b><br />
On Wednesday I will share lessons learned when using the Xtext framework. I will cover a number of topics that I encountered in the Xtext newsgroup and other noteable things that can be important in your daily work with Xtext. If you are already familiar with this cool framework and want to know more about it or just contribute your own experience to the discussion, stop by in the Theater on Wednesday, 2:00 PM.<br />
<br />
<b>Thu 10:30 - 11:00: <a href="http://www.eclipsecon.org/europe2012/sessions/java-performance-mythbuster" target="_blank">Java Performance MythBusters</a></b><br />
The submission of this talk was inspired by a talk by Arno Haase that I attended at the JAX (Arno greatfully gave permission to hijack the title of his talk - thanks for that!). In this session I want to shed light on some myths about Java's performance and often recommended Dos and Don'ts. Come to the Schubartsaal on Thursday 10:30 and I bet you'll be surprised.<br />
<br />
<b>Thu 1:30PM - 2:00PM: <a href="http://www.eclipsecon.org/europe2012/sessions/null-safety-steroids" target="_blank">Null-Safety on Steroids</a></b><br />
Even though the new <a href="http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/news/eclipse-news-part2.html" target="_blank">annotation based null-ness analysis</a> of Eclipse Juno is often very helpful, I am not really fond of the implications that their design has on a reasonable sized code-base. In my last session at this year's ECE I want to share my impressions about null-safety and static analysis. Join me in Silchersaal, Thu 1:30PM if you want to learn about different approaches to tackle the infamous NullPointerException.<br />
<br />
Of course there are other interesting sessions, too, e.g. John Arthorne raises the question about <a href="http://www.eclipsecon.org/europe2012/sessions/eclipse-5" target="_blank">The future of Eclipse</a>. The marriage of <a href="http://www.eclipsecon.org/europe2012/sessions/javafx-osgi-and-e4" target="_blank">JavaFX and e4</a> seems to be a hot topic, too, since JavaFX is a quite powerful rendering technology. And naturally I'm excited about other <a href="http://www.eclipsecon.org/europe2012/sessions/web-development-gwt-and-xtend" target="_blank">Xtend</a> and <a href="http://www.eclipsecon.org/europe2012/sessions/desagn-xtext-cutting-edge" target="_blank">Xtext</a> <a href="http://www.eclipsecon.org/europe2012/sessions/massively-reducing-effort-test-xtext-languages" target="_blank">related</a> <a href="http://www.eclipsecon.org/europe2012/sessions/seven-languages-jvm" target="_blank">content</a>.<br />
<br />
If you are still not convinced, take a look at the schedule yourself and make sure you join the party!Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com0tag:blogger.com,1999:blog-6255758224607466565.post-70095334945155166042012-10-08T22:02:00.000+02:002012-10-08T22:06:49.198+02:00Revisited: Xtend @ JavaOne 2012<p>My talk about <a href="http://xtend-lang.org/" target="_blank">Xtend</a> at this years JavaOne is now <a href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=6630" target="_blank">available</a> in the content catalog on the conference website.</p>
<iframe frameborder="0" height="303" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14640521?hostedIn=slideshare&page=upload" width="360" align="center"></iframe>
<p>
After a quick motivation and the answer to the obvious question "Why the heck did these guys develop yet another JVM language?", I gave a short overview on the basic ideas and design principles behind Xtend. Next up was a demo with different code snippets. Basically it was a walk-through with the examples that can be loaded into everybody's Eclipse as soon as the Xtend SDK is installed. Just select <i>New -> Example... -> Xtend Introductory Examples</i> and there you go.</p>
<p>
The last part of the talk was about <a href="http://blog.efftinge.de/2012/10/current-development-and-future-plans.html" target="_blank">Active Annotations</a>, a unique feature that will be part of the next version of Xtend. To put it into a few words it's Java's annotation processing on steroids. <i>Active annotations</i> may contribute to the translation of Xtend code to Java and even modify the result of that process. They allow to create additional types, use information from other resources or validate the Xtend code according to the annotation's semantics. Along with the powerful means to design creative and expressive APIs and the tight integration with Xtext languages, Xtend's exceptional support for domain-specific languages is raised to the next level by <i>Active Annotations</i>. Stay tuned for more information! </p>Anonymoushttp://www.blogger.com/profile/05886096380926364322noreply@blogger.com1