HaxeFoundation / HaxeFoundation/haxe-evolution

[RFC] XML DSLs

Open
#60 28 comments 13 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
119
Forks
56
PR merge metrics
No merged PRs in 30d

Description

Followup regarding my previous RFC #57

First, thank you for all the comments, after reading the whole discussion and taking time to think about it, I would like to update my proposal.

I agree it is hard to have both the goal of "Universal" block strings and still support XML syntax correctly. Some also mentioned that one of the interesting parts about the feature were some kind of IDE support for syntax highlight and autocomplete, so having the feature too abstract would prevent this.

I still think that some kind of XML DSL syntactic support is - if not absolutely needed - at least interesting enough to have in Haxe. HTML is here to stay for a long time and the XML document model that comes with it can be used for many different other applications as well outside of web client code.

I also think we should not support a single particular DSL such as JSX which spec can evolve and change in unexpected ways, or be entirely deprecated by another alternative syntax - whatever the trending framework happens to be in JS world.

So here's a revised syntax proposal that is trying to ensure that _most_ XML based DSLs will be supported, while still trying to make the strict minimal assumptions about the DSL syntax.

An XML DSL node would be in the form:

``

Where CODE (optional) is explained below.

We would then try match with the corresponding closing XML DSL node in the form:

``

And we would allow self-closing nodes in the form:

``

`CODE` section can be anything, expect the `>` character.

But this creates some invalid syntaxes, for instance the following, because of the comparison inside CODE section:

```haxe
var x =
```

So I propose that CODE additionally check for opening/closing curly braces `{}` and ignore their whole content. So for instance the following would be perfectly valid:

```haxe
var x = ;
```

We could additionally treat `\{` as escape sequence for the following case:

```
var x =
```

I think this version of the syntax gives enough flexibility with minimal assumptions. Using curly braces is done in order to ensure that reentrency is fully supported so any Haxe code within the DSL will be correctly handled.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.