none
M syntax: edit friendliness RRS feed

  • General discussion

  • This does not actually pertain to actual functionality, but I somehow cannot help but to feel the syntax of M could have been more edit-friendly.

    What I mean by this is that common operations, like adding a new line somewhere, removing a line, or swapping the order of two lines, each require additional effort to ensure that (1) all but the last line ends with a comma, (2) the 'in' clause still refers to the final result, and (3) each line still operates on the result of the previous line.

    In a way I feel surprised by this design, since I would think that #1 could be prevented by, say, using a semicolon after each line including the last (of a let-block); #3 and #2 could perhaps be prevented with some 'last result' operator, such as the % symbol in the Wolfram language (link).

    I realize M technically even allows putting lines in a let-block 'out of order', while the 'in' part could contain any statement, though for legibility I'd think most coders would still code 'in order' nonetheless, and would therefore benefit from such an addition, for both brevity and editability.

    I understand the latter proposal may be a bit trickier, while syntax expansions in general would introduce code incompatible with older versions as well. This made me wonder though; would these be considered fair ideas? What were the design decisions for the current comma syntax of M?



    • Edited by Tycho01 Tuesday, July 22, 2014 4:30 PM
    Tuesday, July 22, 2014 4:29 PM

All replies

  • The in clause should refer to any result prior to the last (as it does currently). Being able to put intermediate results in the in clause (not just the final result)  is important for troubleshooting - I use this facility regularly. The lazy evaluation of identifiers means that the developer has the choice of deciding how to arrange these identifiers. Although they will be in a set order most of the time, that order shouldn't be M concern. I have created custom functions that call an embedded custom function (i.e. within the same document). I usually put the custom function call at the end of the let clause to avoid interrupting the flow of reading the main code and to avoid mixing the details of the embedded function within the main code. I'd prefer to define these embedded custom functions elsewhere in the document.

    To me, edit friendliness means stuff like proper indenting and wrapping, syntax highlighting, function auto-complete (including custom functions created in a workbook), function parameter tooltips, function description tooltips etc.

    Tuesday, July 22, 2014 8:13 PM
  • I don't think there are any kind of design notes around specific decisions in the language design. I do know that the two most important guiding principles for the design were

    1) Inspired by the Excel formula language. That's why we have square brackets for field access and curly braces for lists, and it's also why "let" supports out-of-order declaration -- there's no ordering between the cell values in Excel.

    2) Ease of creating tooling like the Power Query editor.

    In any event, we're not currently looking to change or evolve the language :).

    Wednesday, July 23, 2014 1:54 PM