<div dir="ltr"><div><div><div><div><div><div>Yeah the Swift/T work was integrating at a slight different point<br><br></div><div>The Swift/T compiler's pipeline is essentially<br></div>Antlr Parser -> [AST] -> Frontend (Typechecking, semantic analysis, etc) -> [IR-1] -> Middleend (optimisation, etc) -> [IR-2] -> Code Generation -> [Tcl]<br><br></div>The Swift/K compiler's pipeline is:<br><br></div>Antlr Parser -> [AST] -> serialisation -> [XML] -> Swift/K frontend -> Code Generation -> [Karajan]<br><br><br></div>Mihael is talking about cutting out the first few steps from Swift/K that don't achieve much.<br><br></div>The other, larger, project is to add a backend to Swift/T that generates karajan, i.e. graft it on alongside the Tcl code generation step much later in the process.<br><br></div>- Tim<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 April 2015 at 00:42, 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>
Yes. I made some progress in that direction, but other things eventually<br>
got in the way and I stopped working on it.<br>
<br>
In the mean time, we do have to work with the existing parser.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sat, 2015-04-18 at 00:38 -0500, Michael Wilde wrote:<br>
> Mihael,<br>
><br>
> Weren't you at one time looking into using the Swift/T parser for Swift/K?<br>
><br>
> Or the Swift/T ANTLR grammar?<br>
><br>
> I thought this was at least mentioned in a Swift team meeting.<br>
><br>
> - Mike<br>
><br>
><br>
> On Fri, Apr 17, 2015 at 11:31 PM, Tim Armstrong <<a href="mailto:tim.g.armstrong@gmail.com">tim.g.armstrong@gmail.com</a>><br>
> wrote:<br>
><br>
> >  Makes sense to me if it simplifies the code - I'm not sure how much<br>
> > ongoing maintenance overhead it is to keep up the additional<br>
> > transformations.<br>
> ><br>
> >  - Tim<br>
> ><br>
> > On 17 April 2015 at 22:18, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>> wrote:<br>
> ><br>
> >> 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">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>
> >><br>
> ><br>
> ><br>
<br>
<br>
</div></div></blockquote></div><br></div>