Change Q data dumps to conform to the new object constructor syntax

[masak]

A piece of code like this:

macro foo() {
    my x = 7;
    return quasi {
        say(x);
    };
}

foo();

has a Qtree which currently stringifies to this:

Statements
  Macro[foo]
    Parameters

    Statements
      My
        Identifier[x]
        Infix[=]
          Identifier[x]
          Int[7]
      Return
        Quasi
          Statements
            Expr
              Call
                Identifier[say]
                Arguments
                  Identifier[x]
  Expr
    Call
      Identifier[say]
      Arguments
        Identifier[x]

That stringification has served us well, but I think it's time to replace it with something more 007-native: the new proposed object constructor syntax. That same Qtree above would then render as this:

Q::Statements [
    Q::Statement::Macro {
        ident: Q::Identifier "foo",
        parameters: Q::Parameters [],
        statements: Q::Statements [
            Q::Statement::My {
                ident: Q::Identifier "x",
                assignment: Q::Infix::Assignment {
                    lhs: Q::Ident "x",
                    rhs: Q::Literal::Int 7
                }
            },
            Q::Statement::Return {
                expr: Q::Quasi {
                    statements: [
                        Q::Statement::Expr {
                            expr: Q::Postfix::Call {
                                expr: Q::Identifier "say",
                                arguments: Q::Arguments [ 
                                    Q::Identifier "x"
                                ]
                            }
                        }
                    ]
                }
            }
        ]
    },
    Q::Statement::Expr {
        expr: Q::Postfix::Call {
            expr: Q::Identifier "say",
            arguments: Q::Arguments [
                Q::Identifier "x"
            ]
        }
    }
]

A bit more verbose. But also much more in line with where 007 is heading in general.

[masak]

Yeah, got it. And wow is it an improvement!

Q::Statements [
    Q::Statement::Macro {
        ident: Q::Identifier "foo",
        parameters: Q::Parameters [],
        statements: Q::Statements [
            Q::Statement::My {
                ident: Q::Identifier "x",
                assignment: Q::Infix::Assignment {
                    lhs: Q::Identifier "x",
                    rhs: Q::Literal::Int 7
                }
            },
            Q::Statement::Return Q::Quasi Q::Statements [
                Q::Statement::Expr Q::Postfix::Call {
                    expr: Q::Identifier "say",
                    arguments: Q::Arguments [Q::Identifier "x"]
                }
            ]
        ]
    },
    Q::Statement::Expr Q::Postfix::Call {
        expr: Q::Identifier "say",
        arguments: Q::Arguments [Q::Identifier "x"]
    }
]

My hand-written translation in the OP brought the line count up from 23 to 37. But the stringifier brings it back down to 25, so it ties in line count with the original format. It's more informative, and more compact at the same time.

I told it that if a Q type only has one attribute, then go ahead and abbreviate it on the same line. Apparently it's better than I am at finding those cases. 😊

Some hacky beautification is applied to remove attributes that don't add any information, and to improve the presentation order of some other attributes.

[masak]

Today I was struck by the thought that the stringification of objects might be vulnerable to cyclical references between objects. Since the stringification doesn't check for cycles (à la Data::Dumper), any cycle will just cause the stringifier to disappear into the black lagoon.

But then I realized that there can be no cycles. For the same reason there can be none in Git. Objects can only be created to refer (publicly) to things with a strictly older time stamp. Even .update and .extend create entirely new object, kind of like amend/cherry-pick/rebase operations.

To get a "backlink", one would have to return one from a method rather than have it as a public attribute. (This way, one could still have doubly linked lists, trees, etc.) I guess it's the price being paid for the immutability-heavy design. From the point of view of stringification, it certainly makes things easier.