RFC: new chirp and dsl! syntax

[nicopap]

I'm proud of what I built. Now that we have something working. It is time to think a bit more carefully about the chirp and dsl! syntax.

Summary of proposed syntax changes and poll at the end.

Note that I will only consider winners if there are in my preference list or someone made a compelling argument in its favor.

What's chirp and dsl! syntax

It is the shared syntax used in the dsl! macro from cuicui_dsl and the .chirp file format in cuicui_chirp.

The two share — if not the exact same syntax — a similar enough syntax that it should be possible to copy/paste your dsl! macro content into an independent file and load it as a .chirp file using asset_server.load::<Chirp, _>("scene.chirp").

The current syntax is as follow:

row("Twenty", rules(40px, 41%)) {
    spawn("23", rules(50%, 51px), empty_px 60);
    spawn("22", empty_px 61);
}
row("10 wow", rules(10px, 11%)) {
    spawn("11", rules(20%, 21px), empty_px 30);
    spawn("12", empty_px 31);
}

Planned syntax

I already like the syntax, but it might be offputting to some for the following reasons:

1. Method call without parenthesis (eg: empty_px 60 "calls" the empty_px method with argument 60)
2. string literal as name (the fact that "10 wow" and rules(10px, 11%) can be at the same location as syntax elements)
3. Two ways of calling a method (eg: row("10", margin 10) is equivalent to entity("10", margin 10, row)
4. Some people are hermetic to the concept of anything else but HTML being used to define UIs

While I can't solve (4), I plan to fix the other 3 points.

The current syntax is not exactly completely alien, especially for UI. It comes from:

• QML: the javascript inspired markup for Qt's new UI declaration system
• KDL: The node-based markup similar to Dlang's config.
• text FBX: yep, it does look an awful lot like the chirp syntax, doesn't it?

This is not up to debate. I will replace the "parent node syntax" by entity name declaration & remove the literal syntax for names. So the previous snippet will look as follow:

Twenty(rules(40px, 41%), row) {
    23(rules(50%, 51px), empty_px 60);
    22(empty_px 61);
}
"10 wow"(rules(10px, 11%), row) {
    11(rules(20%, 21px), empty_px 30);
    12(empty_px 31);
}

The name, instead of being a method special-case, will be the "head identifier" of a statement.

The question is: can I do better for the rest of the grammar. Can it be more familiar for users?

Original

Twenty(rules(40px, 41%), row) {
    23(rules(50%, 51px), empty_px 60);
    22(empty_px 61);
}
"10 wow"(
	long(100, 3434, "some text"),
	with_single_argument "some unique argument",
	rules(10px, 11%),
	row,
) {
    11(rules(20%, 21px), empty_px 30);
    12(empty_px 31);
}
row("0or1argMethods", width 30, height 40);

KDL-light

Twenty rules(40px, 41%) row {
    23 rules(50%, 51px) empty_px(60);
    22 empty_px(61);
}
"10 wow"
	long(100, 3434, "some text")
	with_single_argument("some unique argument")
	rules(10px, 11%)
	row
{
    11 rules(20%, 21px) empty_px(30);
    12 empty_px(31);
}
0or1argMethods row width(30) height(40) margin(23);

• No more parenthesis around the method list
• No more commas between methods
• No more "signle argument" method syntax, even with a single argument, we
  must use parenthesis

KDL-light with method commas

Twenty rules(40px, 41%), row {
    23 rules(50%, 51px), empty_px 60;
    22 empty_px 61;
}
"10 wow" 
	long(100, 3434, "some text"),
	with_single_argument "some unique argument",
	rules(10px, 11%),
	row,
{
    11 rules(20%, 21px), empty_px 30;
    12 empty_px 31;
}
0or1argMethods row, width 30, height 40, margin 23;

• No more parenthesis around the method list
• Keep comma between methods, so we can keep the "single argument" method syntax

KDL-light with equal

Twenty rules(40px, 41%) row {
    23 rules(50%, 51px) empty_px=60;
    22 empty_px=61;
}
"10 wow" 
	long(100, 3434, "some text")
	with_single_argument="some unique argument"
	rules(10px, 11%)
	row
{
    11 rules(20%, 21px) empty_px=30;
    12 empty_px=31;
}
0or1argMethods row width=30 height=40 margin=23;

• No more parenthesis around the method list
• Modify "single argument" method syntax to use an equal sign

KDL-light with colon

Twenty rules(40px, 41%) row {
    23 rules(50%, 51px) empty_px: 60;
    22 empty_px: 61;
}
"10 wow" 
	long(100, 3434, "some text")
	with_single_argument: "some unique argument"
	rules(10px, 11%)
	row
{
    11 rules(20%, 21px) empty_px: 30;
    12 empty_px: 31;
}
0or1argMethods row width: 30 height: 40 margin: 23;

• No more parenthesis around the method list
• Modify "single argument" method syntax to use a colon

After looking at those, I feel like keeping the parenthesis around the
method list is ve3ry useful in term of readability.

OG-dsl without commas but with colons

Twenty(rules(40px, 41%) row) {
    23(rules(50%, 51px) empty_px: 60);
    22(empty_px: 61);
}
"10 wow"(
	long(100, 3434, "some text")
	with_single_argument: "some unique argument"
	rules(10px, 11%)
	row
) {
    11(rules(20%, 21px) empty_px: 30);
    12(empty_px: 31);
}

One issue with this is that with large method lists that span several lines,
it might be difficult to distinguish a method call from a statement. Only
hint is that we don't terminate with a ; or {}.

Though this is true of every other proposed syntaxes as well.

We could also remove ; for the same reason we can remove ,. This can't
be done without the parenthesis around the method list.

Another issue is syntax error detection: entity(method1 arg1) is valid
syntax, but it is two methods, not a single one with two arguments.

It's a bad result if someone forgot to add a : between the method and its
single argument.

But the error message might be good enough to get the hint to people.

We could just drop the : style to avoid the pitfall.

OG-dsl without commas nor semicolons nor colons

Twenty(rules(40px, 41%) row) {
    23(rules(50%, 51px) empty_px(60))
    22(empty_px(61))
}
"10 wow"(
	long(100, 3434, "some text")
	with_single_argument("some unique argument")
	rules(10px, 11%)
	row
) {
    11(rules(20%, 21px) empty_px(30))
    12(empty_px(31))
}
0or1argMethods(row width(30) height(40) margin(23));

It's much cleaner and we don't lose on readability.

I just think forcing the () on single-argument methods is too noisy.
Especially when most methods will have 0 or 1 argument.

Though not having a magic syntax for single arg methods is appealing

OG-dsl without commas nor semicolons, but with colons

Twenty(rules(40px, 41%) row) {
    23(rules(50%, 51px) empty_px: 60)
    22(empty_px: 61)
}
"10 wow"(
	long(100, 3434, "some text")
	with_single_argument("some unique argument")
	rules(10px, 11%)
	row
) {
    11(rules(20%, 21px) empty_px: 30)
    12(empty_px: 31)
}
0or1argMethods (row width: 30 height: 40 margin: 23)

Removing commas turns out to be very confusing with semicolons.

OG-dsl without commas nor semicolons, but with equals

Twenty(rules(40px, 41%) row) {
    23(rules(50%, 51px) empty_px=60)
    22(empty_px=61)
}
"10 wow"(
	long(100, 3434, "some text")
	with_single_argument("some unique argument")
	rules(10px, 11%)
	row
) {
    11(rules(20%, 21px) empty_px=30)
    12(empty_px=31)
}
0or1argMethods (row width=30 height=40 margin=23)

Removing commas turns out to be very confusing with semicolons. We can however
use = to visually put together methods and their signle argument

Summary

Original

• () around method list
• , between methods
• 1arg methods: space
• ; between leaf statements

; and , are noisy, 1arg method is surprising coming from Algol-like

KDL-light

• no () around method list
• no , between methods
• 1arg methods: ()
• ; between leaf statements

Lack of symmetry between methods and statements, ; is noisy, () for
1arg methods noisy

KDL-light with method commas

• no () around method list
• , between methods
• 1arg methods: space
• ; between leaf statements

Lack of symmetry between methods and statements,
; and , are noisy, 1arg method is surprising coming from Algol-like

KDL-light with equal

• no () around method list
• no , between methods
• 1arg methods: =
• ; between leaf statements

Closer to KDL, Lack of symmetry between methods and statements,
; is noisy

KDL-light with colon

• no () around method list
• no , between methods
• 1arg methods: :
• ; between leaf statements

Closer to JSON, Lack of symmetry between methods and statements,
; is noisy. Two subsequent 1arg methods without , between them is very
confusing

OG-dsl without commas but with colons

• () around method list
• no , between methods
• 1arg methods: :
• ; between leaf statements

Symmetry between methods and statements, ; is noisy,
Two subsequent 1arg methods without , between them is very
confusing.

OG-dsl without commas nor semicolons nor colons

• () around method list
• no , between methods
• 1arg methods: ()
• no ; between leaf statements

Best symmetry between methods and statements,
() for 1arg methods noisy.

OG-dsl without commas nor semicolons, but with colons

• () around method list
• no , between methods
• 1arg methods: :
• no ; between leaf statements

Symmetry between methods and statements,
Two subsequent 1arg methods without , between them is very
confusing.

OG-dsl without commas nor semicolons, but with equals

• () around method list
• no , between methods
• 1arg methods: =
• no ; between leaf statements

Symmetry between methods and statements.

Personal ranking

1. OG-dsl without commas nor semicolons, but with equals
2. OG-dsl without commas nor semicolons nor colons

Any other feel just so wrong to me.