<div dir="ltr">Mihael,<div><br></div><div>Weren't you at one time looking into using the Swift/T parser for Swift/K?</div><div><br></div><div>Or the Swift/T ANTLR grammar?</div><div><br></div><div>I thought this was at least mentioned in a Swift team meeting.<br><div><br></div><div>- Mike</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 11:31 PM, Tim Armstrong <span dir="ltr"><<a href="mailto:tim.g.armstrong@gmail.com" target="_blank">tim.g.armstrong@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div dir="ltr">
<div>Makes sense to me if it simplifies the code - I'm not sure how much ongoing maintenance overhead it is to keep up the additional transformations.<span class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></div><span class="HOEnZb"><font color="#888888">
- Tim<br>
</font></span></div><div><div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 17 April 2015 at 22:18, Mihael Hategan <span dir="ltr">
<<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I think we should remove the intermediate XML (aka. swiftx).<br>
<br>
It was initially meant to be an abstract representation (like Java<br>
bytecode) so that multiple backends could be implemented easily.<br>
However, the reality is that the XML is a direct representation of the<br>
swift/K parse tree. The other reality is that the only potential place<br>
that could have used this as intended (swift/T) didn't.<br>
<br>
Here's what happens in the code:<br>
<br>
1. swift parser parses the .swift code and generates a representation of<br>
the parse tree as StringTemplate objects.<br>
<br>
2. the StringTemplate tree gets serialized to XML using swiftscript.stg<br>
(a template collection). This gets saved to disk.<br>
<br>
3. XML beans are generated from the schema and the generated XML is<br>
loaded into a tree of XML Beans.<br>
<br>
4. The Karajan class traverses the XML Beans tree and generates karajan<br>
code (using StringTemplate objects).<br>
<br>
I think that everything between steps 1 and 4 is just Rube Goldberg<br>
code. It translates the same data structure between StringTemplate to<br>
XML to XML Beans. It could all (easily I might add) be replaced with<br>
nice Java classes representing the parse tree.<br>
<br>
Opinions?<br>
<br>
Mihael<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</blockquote>
</div>
<br>
</div>
</div></div></div>

</blockquote></div><br></div>