[Swift-devel] intermediate XML

[Tim Armstrong]

Yeah the Swift/T work was integrating at a slight different point

The Swift/T compiler's pipeline is essentially
Antlr Parser -> [AST] -> Frontend (Typechecking, semantic analysis, etc) ->
[IR-1] -> Middleend (optimisation, etc) -> [IR-2] -> Code Generation ->
[Tcl]

The Swift/K compiler's pipeline is:

Antlr Parser -> [AST] -> serialisation -> [XML] -> Swift/K frontend -> Code
Generation -> [Karajan]


Mihael is talking about cutting out the first few steps from Swift/K that
don't achieve much.

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.

- Tim

On 18 April 2015 at 00:42, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> Hi,
>
> Yes. I made some progress in that direction, but other things eventually
> got in the way and I stopped working on it.
>
> In the mean time, we do have to work with the existing parser.
>
> Mihael
>
> On Sat, 2015-04-18 at 00:38 -0500, Michael Wilde wrote:
> > Mihael,
> >
> > Weren't you at one time looking into using the Swift/T parser for
> Swift/K?
> >
> > Or the Swift/T ANTLR grammar?
> >
> > I thought this was at least mentioned in a Swift team meeting.
> >
> > - Mike
> >
> >
> > On Fri, Apr 17, 2015 at 11:31 PM, Tim Armstrong <
> tim.g.armstrong at gmail.com>
> > wrote:
> >
> > >  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.
> > >
> > >  - Tim
> > >
> > > On 17 April 2015 at 22:18, Mihael Hategan <hategan at mcs.anl.gov> wrote:
> > >
> > >> Hi,
> > >>
> > >> I think we should remove the intermediate XML (aka. swiftx).
> > >>
> > >> It was initially meant to be an abstract representation (like Java
> > >> bytecode) so that multiple backends could be implemented easily.
> > >> However, the reality is that the XML is a direct representation of the
> > >> swift/K parse tree. The other reality is that the only potential place
> > >> that could have used this as intended (swift/T) didn't.
> > >>
> > >> Here's what happens in the code:
> > >>
> > >> 1. swift parser parses the .swift code and generates a representation
> of
> > >> the parse tree as StringTemplate objects.
> > >>
> > >> 2. the StringTemplate tree gets serialized to XML using
> swiftscript.stg
> > >> (a template collection). This gets saved to disk.
> > >>
> > >> 3. XML beans are generated from the schema and the generated XML is
> > >> loaded into a tree of XML Beans.
> > >>
> > >> 4. The Karajan class traverses the XML Beans tree and generates
> karajan
> > >> code (using StringTemplate objects).
> > >>
> > >> I think that everything between steps 1 and 4 is just Rube Goldberg
> > >> code. It translates the same data structure between StringTemplate to
> > >> XML to XML Beans. It could all (easily I might add) be replaced with
> > >> nice Java classes representing the parse tree.
> > >>
> > >> Opinions?
> > >>
> > >> Mihael
> > >>
> > >> _______________________________________________
> > >> Swift-devel mailing list
> > >> Swift-devel at ci.uchicago.edu
> > >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> > >>
> > >
> > >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150419/3cc955f9/attachment.html>