Hi Sergey
The Xtext to LPG transformation will be potentially useable for any
application that wants a smaller Xtext compiler, though of course
I'll concentrate on features that are relevant to OCL. So I may
ignore syntactic predicates and enum rules, and perhaps hard code
some of the LPG preamble. In principle the variation between
LexerTemplateA/B/C/... should also be auto-generated, but that's
definitely beyond my scope. It will work for OCL and OCL-like usage.
Arbitrary usage may require more work.
Regards
Ed Willink
On 02/03/2012 08:09, Sergey Boyko wrote:
Hi Ed, Adolfo,
Thank you for the explanation. I wrongly interpret mentioned
conversion as one related to QVTo grammar.
Some questions are in-ined below.
Regards,
Sergey
On Thu, Mar 1, 2012 at 9:28 PM, Ed Willink <ed@xxxxxxxxxxxxx>
wrote:
Hi Sergey
Thanks. I found the QVTo standalone Bugzilla as I prepared
to raise a Bugzilla with my own inferior solution. Pity its
not in the documentation.
While QVTo continues use the Ecore binding, the various
Xtext activities are irrelevant to QVTo. However, once the
Pivot model is promoted and all the elements of tool
auto-generation from a specification are in place, it may be
appropriate to provide the accurate models for the QVT
specification and then auto-generate large parts of the QVT
tooling from the specification models. This is my plan for
QVTd.
The Xtext to LPG conversion is a useful part of this tooling
since it will achieve a 10-fold reduction in parser size, a
corresponding reduction in JIT start-up time, and perhaps a
2-fold improvement in parsing time, without losing the
benefits of the very compact Xtext grammar and the
associated auto-generation of many editor capabilities.
So your goal is to provide alternative parser (LPG in place of
ANTLR) for Xtext grammar? This will be applicable solely for
OCL ?
The CST used by the Xtext to LPG conversion will be an
Xtext-friendly CST, so that the auto-generated name lookup
and CST to AST conversions will be equally applicable to
usage within the Xtext editor using ANTLR or in the OCL
compiler using LPG. I see no prospect of providing an
upgrade path for the existing CST and with auto-generation
of everything using the CST, I see no point in preserving
the old CST.
I don't understand what you mean by "Could you please point
me where QVTo *.xtex is persisted?". Perhaps you're being
confused by "QVTo: *.xtext -> *.xtext.XBNF"; my use of
QVTo as an M2M transformation tool to transform from an
Xtext file/model to further models. You can find the QVTo
transformations in the o.e.o.examples.xtext2lpg plugin in
the bug/369123a branch.
Ok, thanks once again for the explanation. I misunderstood the
context of the activity. Now I got that QVTo is used only for
transformation (as it best be used :)
Regards
Ed Willink
On 01/03/2012 16:51, Sergey Boyko wrote:
Hi Ed,
Could you please describe in more details what is
"Xtext to LPG" means for QVTo. Could you please point
me where QVTo *.xtex is persisted?
About QVTo statndalone execution; look at http://wiki.eclipse.org/M2M/QVTO/New_and_Noteworthy/Helios#Milestone_5
Regards,
Sergey
On Wed, Feb 29, 2012 at 11:56
AM, Ed Willink <ed@xxxxxxxxxxxxx>
wrote:
Hi
I made a relatively small Xtext grammar change and
suddenly got stupid syntax errors, probably
because a magic backtracking precedence flipped. I
therefore started updating the 'equivalent' LPG
grammar to look for a conflict and realized that
the time had come to look at automated Xtext to
LPG conversion; it's relatively easy.
I've therefore developed/am developing a Tx
cascade
QVTo: *.xtext -> *.xtext.XBNF to get a fully
referential EBNF model from the Xtext CST
QVTo: *.xtext.XBNF -> *.xtext.normal.XBNF to
convert to a disjunct of conjuncts BNF
QVTo: *.normal.XBNF -> *.inline.XBNF to
re-inline non-recursive references that were
originally from a single rule
Acceleo: *.inline.XBNF -> *.g, *.gi
(XBNF is Xtext BNF, i.e BNF with model
annotations)
Currently plausible KWLexer and Parser grammars
are generated, Lexer still todo; the Xtext and LPG
styles are very different.
Action code still to do; should be easy with all
the model annotations.
Unfortunately there is no QVTo standalone support
so I also had to develop that and the
corresponding MWE integration.
The build scripts are in the build plugin. The
transformations in the examples.xtext2lpg plugin.
Since only the build plugin has QVTo dependencies
and neither of the above plugins are in the Tools
build, I don';t think that there is any releng
impact.
Regards
Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this
message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4843 -
Release Date: 02/29/12
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4844 - Release Date:
03/01/12
|