[QBS] syntactic sugar

[joerg.bornemann at nokia.com]

Jan Krieger wrote:

> I already proposed this in the blog, but will post it again here:

Thanks and welcome to the mailing list!

> I think a bit of syntactic sugar would be good for qbs:
> -  Depends { name: "Qt.core" }
>    looks somehow uggly, why not simply write
>     Depends: "Qt.core"
>    and leave the extended syntax as the non-default alternative, if
>    you need to specify something more general?

Without any changes to the parser we could just use a property binding.

Product {
    name: "foo"
    depends: ["cpp", "egon", "olsen"]
}

Already simpler. You propose this

Product {
    name: "foo"
    depends: "cpp"
    depends: "moo"
}

You cannot have more than one binding unless we clearly define what it means.

> - the same for this construct:
>     Group {
>       condition: qbs.target == "windows"
>       files: [
>         "harddiskdeleter_win.cpp",
>         "blowupmonitor_win.cpp",
>         "setkeyboardonfire_win.cpp"
>       ]
>     }
>    why not simply write:
>     Group (condition: qbs.target == "windows") {
>       files: [
>         "harddiskdeleter_win.cpp",
>         "blowupmonitor_win.cpp",
>         "setkeyboardonfire_win.cpp"
>       ]
>     }

I cannot see why this is simpler. You're adding two more characters after all. ;-)

> - also (just to mention it again) somebody also already proposed to
>    allow for string lists without delimiters for each entry, e.g.:
>       files: @(
>         harddiskdeleter_win.cpp,
>         blowupmonitor_win.cpp,
>         setkeyboardonfire_win.cpp,
>         "but with whitespaces.cpp"
>       ]
>    this was taken from: https://bugreports.qt-project.org/browse/QBS-58

Yes I'm all for it. This of course needs adjustments of the grammar.

Any comments on the flavor of the escape sign?
@( ... files ... )
<<< ... files ... >>>
FILE_LIST_IS_STARTING_RIGHT_HERE ... files ... FILE_LIST_IS_DONE_NOW_BELIEVE_ME

If there are no better ideas, we'll take Ossi's proposal with the @.

> BTW: Is there a definition of the QML syntax in the form of a Extended
> Backus–Naur Form (EBNF)  or something else, then we could make exact
> proposals for a changed syntax.

Well not exactly EBNF but we have the reference grammar in qmljs.g.
A more human readable form can be produced by invoking
    qlalr --verbose src/lib/parser/qmljs.g


BR,

Jörg