I've spent a few hours digging around I can't find any examples of the syntax tree/calls that I need to construct to incorporate it.
Does anyone have any pointers on getting this working?
M
jodastephenFri 18 Dec 2009
I've also got the basics of an XML DSL basically working. Mine parses the XML in the plugin and creates actual XElem and XAttr elements from the plugin. (This means that the XML is parsed and validated at compile time :-)
I had problems with the DSL output needing to be an expression (no way to create local variables and statements).
I also wanted to include $type style Fantom expression snippets, but there is no common support for that yet (AFAIK).
DanielFathFri 18 Dec 2009
It is logical that DSL doesn't take $type into account, but there should be a way for this to be possible. Most logical thing to do is to allow nesting custom code in it:
<| <p class="<|$type|>">$message</p> |>
Something like this, perhaps. Though this might not work for unknown reasons.
jodastephenFri 18 Dec 2009
We don't need for DSL to support $a.b.c expressions by default. Its entirely up to the parser of the DSL to decide what is and isn't a sub-expression. What we do need is a way of passing the sub-expression a.b.c back to a generic part of the DSL plugin to return an AST node to use at that point.
brianFri 18 Dec 2009
I had problems with the DSL output needing to be an expression (no way to create local variables and statements).
The DSL has to resolve to some expression, but the DslPlugin can manipulate the AST also in its compile callback.
I've spent a few hours digging around I can't find any examples of the syntax tree/calls that I need to construct to incorporate it.
Eventually I want to have a nice API which takes an expr string and does all the work to turn it into a resolved AST. But I don't have that, so it requires a plugin provider to do all the work right now. Fansh has the same problem too.
KevinKelleySat 19 Dec 2009
This is has some interesting possibilities, I'm trying to come to grips with How It All Works. Just ran into the following on the E language site, section on QuasiLiterals
Our XML QuasiParser already solves this for us. The expression
xml`<Sect1><Para>For example, ${Math("x**2 + x**3")} is nice</Para></Sect1>`
Produced the same DOM tree as this XML:
<Sect1>
<Para>For example, <apply>
<plus/>
<apply>
<power/>
<ci>x</ci>
<cn>2</cn>
</apply>
<apply>
<power/>
<ci>x</ci>
<cn>3</cn>
</apply>
</apply>is nice</Para>
</Sect1>
which is interesting, building a domain-specific language directly into the AST. Haven't got far into this yet, just saying it looks cool.
KevinKelleySat 19 Dec 2009
...the above example is about parsing a DSL into an ast expression tree; a later example shows manipulating an expression by matching node patterns:
msl Fri 18 Dec 2009
Hi Everybody!
I've spent a couple of hours playing with a DSL plugin to allow XML (or more importantly for my needs well formed HTML) to be inlined.
The current working code can be found at http://github.com/martinlau/xparserdsl.
Usage goes something like:
content := XParser<| <p class="message">This is an important message</p> |>
However, I'd also like to include Str interpolation to enable things like:
type := "warning"
message := "You did something wrong"
content := XParser<| <p class="$type">$message</p> |>
I've spent a few hours digging around I can't find any examples of the syntax tree/calls that I need to construct to incorporate it.
Does anyone have any pointers on getting this working?
M
jodastephen Fri 18 Dec 2009
I've also got the basics of an XML DSL basically working. Mine parses the XML in the plugin and creates actual XElem and XAttr elements from the plugin. (This means that the XML is parsed and validated at compile time :-)
I had problems with the DSL output needing to be an expression (no way to create local variables and statements).
I also wanted to include
$type
style Fantom expression snippets, but there is no common support for that yet (AFAIK).DanielFath Fri 18 Dec 2009
It is logical that DSL doesn't take
$type
into account, but there should be a way for this to be possible. Most logical thing to do is to allow nesting custom code in it:Something like this, perhaps. Though this might not work for unknown reasons.
jodastephen Fri 18 Dec 2009
We don't need for DSL to support
$a.b.c
expressions by default. Its entirely up to the parser of the DSL to decide what is and isn't a sub-expression. What we do need is a way of passing the sub-expressiona.b.c
back to a generic part of the DSL plugin to return an AST node to use at that point.brian Fri 18 Dec 2009
The DSL has to resolve to some expression, but the DslPlugin can manipulate the AST also in its compile callback.
Eventually I want to have a nice API which takes an expr string and does all the work to turn it into a resolved AST. But I don't have that, so it requires a plugin provider to do all the work right now. Fansh has the same problem too.
KevinKelley Sat 19 Dec 2009
This is has some interesting possibilities, I'm trying to come to grips with How It All Works. Just ran into the following on the E language site, section on QuasiLiterals
which is interesting, building a domain-specific language directly into the AST. Haven't got far into this yet, just saying it looks cool.
KevinKelley Sat 19 Dec 2009
...the above example is about parsing a DSL into an ast expression tree; a later example shows manipulating an expression by matching node patterns:
to do, in this example, symbolic differentiation of math formulas.