-
Notifications
You must be signed in to change notification settings - Fork 42
Simpler Templating suggestion
As a potential replacement for three phase 3 transformation/codegen, I propose this simpler scheme which merges the transformation with simple strring templating (based of jinja2 templating, but not set in stone obviously).
This is 15min of thinking and likely will need lots of discussion to mak workable!
Lets just forget about the grammar input use a simple !view to do the outputting:
XSDCodegen:
!view XMLFile(app <: sysl.App) -> string:
app -> (:
|<?xml version="1.0" encoding="UTF-8"?>
|<xsd:schema>
app.types where ("xml_root" in .value.attrs.patterns) -> (e:
| <xs:element name="{% e.key | stripTail("Type") %}" type="{% e.key %}/>
)
app.types -> (e:
| <xs:complexType name="{% e.key %}">
| <xsd:sequence>
e.fields -> (field:
| <xs:element name="{% field.name %}" type="{% field.type.name %}" />
FormatComment(field, prefix=" ", wrap=80) # FormatComment is actually a view (with named params if that is legal)
)
| <sequence>
| <complexType>
)
|</schema>
)
Lets pretend the above view was syntactically correct, lines beginning with | are treated as output text with very simple token replacement (i.e anything between {% %} is template-ing (see https://jinja.palletsprojects.com/en/2.10.x/templates/ for my inspiration). Other lines are treated as the existing view syntax.
My hope is that even without explanation of the output file or the templating you could make a educated guess as to what the output would look like after this view is called.
Pros:
- No target language grammar required
- Allows the sysl writer to see exactly what how a sysl object is getting written to the output (instead of going through 2 or 3 different AST transforms+grammar) - Simpler execution model for users to understand
- Provides full access to the sysl tranform views and types Cons:
- ?