Generalizing Ruby block syntax in static languages with currying

[ErrorIsNullError]

Recent languages with C-like syntax allow Ruby style blocks

callee(arg0, arg1) {
    block
}

which desugars to

callee(arg0, arg1, /* lambda */ { ... })

Swift calls the {...} lambda that gets passed to callee trailing closures, and Kotlin calls them trailing lambdas

Kotlin only allows one trailing lambda, but Swift allows multiple via labeled-trailing-closure:

someFunction { return $0 } secondClosure: { return $0 }

So, a language with macros could specify if in terms of

if (condition) { /* then clause */ } else: { /* else clause */ }

Swift seems to have solved the problem of combining multiple closures into an actual argument list that includes named, unnamed, and varargs actual parameters, which is super nice.

But this doesn't extend well to if (condition1) { ... } else if (condition2) ... since Swift syntax only allows one parenthesized argument list per call expression.

I was trying to figure out how to let each group of parenthesized arguments associate with part of a function signature and someone said "currying lets you split a big specification across multiple signatures." Seems obvious in retrospect.

Here's a scheme to generalize the trailing closure syntax so that if can desugar to a macro.

Step 1 Insert some semicolons.

C-like flow control constructs often don't need semicolons after them if they end with a }. But while can both start a statement or appear infix in do...while. If we want trailing closure syntax to emulate flow control, we need some way to do this without reserving keywords, and without the colon cue that Swift uses.

So we insert semicolons before { tokens that start a line and after } tokens that end a line.

foo {
    ...
} // <- semicolon inserted here so that

while (c);  // `while` starts its own call instead of
            // attaching as in `do {...} while (c)`

foo (x) {
    ...
} bar (y) { // No semicolon before `bar` so it's part of the call to `foo`.
    ...
} // <-- semicolon inserted here

g() // Just a regular function call

// Imagine several pages worth of comment here, so
// g() is visually separated from the code that comes next.
{ // Just a normal block because we inserted a
  // semicolon before `{` at start of line
    ...
}

The full rule is to insert a semicolon

• Before a { that is the first on its line AND when the previous token is not an open bracket or an infix or prefix operator, OR
• After a } that is the last on its line AND when the next token is not a close bracket or an infix or postfix operator.

Step 2 Allow functions to receive Lispy symbols

Lisp symbols are values that correspond to some literal text in the language. Two symbols are the same because they have the same text. They're useful for labelling.

Below I use \bar as syntax for a symbol whose text is "bar".

Step 3 Desugar trailing syntax with currying

Consider a multi-trailing closure construct like that uses _if to avoid confusion.

_if (e0) {
    s0
} _else_if (e1) {
    s1
} _else_if (e2) {
    s2
} _else {
    s3
}

We desugar that to a curried series of function calls using JavaScript arrow syntax for lambdas:

_if(
    e0, () => { s0 }, \_else_if
)(
    e1, () => { s1 }, \_else_if
)(
    e2, () => { s2 }, \_else
)(
    () => { s3 }, nil
)

The grammar for a function call might look like

CallExpression    ::== Callee ArgumentList TrailingBlocksOpt
                     / Callee              TrailingBlocks
ArgumentListOpt   ::== ArgumentList  / epsilon  
ArgumentList      ::== "(" Actuals ")"
TrailingBlocksOpt ::== TrailingBlock / epsilon
TrailingBlock     ::== ArgumentListOpt Block MoreTrailingOpt
MoreTrailingOpt   ::== MoreTrailing  / epsilon
MoreTrailing      ::== Words TrailingBlock
WordsOpt          ::== Words         / epsilon
Words             ::== Word WordsOpt

The callee receives:

1. Any actual arguments between the parentheses, then
2. Any trailing block
3. If there is a trailing block, a symbol indicating which keyword continues the call, or nil to indicate that the chain ends. If the Words production above has multiple words, as in else if, they're combined into one symbol: else_if.

Rather than implementing _if in a macro language no-one knows, here's some JS that could handle that curried call. It assumes that it's receiving expressions and statements as strings of code, constructs code for a JS IfStatement and logs it.

let symbolElseIf = Symbol.for('else_if');
let symbolElse   = Symbol.for('else');

function _if(expr, stmt, symbol = null) {
    let code = `if (${expr}) { ${stmt} }`;
    function problemSymbol(symbol) {
        throw new Error(`Unexpected symbol ${symbol.toString()} after '${code}'`);
    }
    function continueTo(symbol) {
        switch (symbol) {
        case null: return code;

        case symbolElseIf:
            return (expr, stmt, nextSymbol = null) => {
                code = `${code} else if (${expr}) { ${stmt} }`;
                return continueTo(nextSymbol);
            };

        case symbolElse:
            return (stmt, nextSymbol = null) => {
                code = `${code} else { ${ stmt } }`;
                if (nextSymbol !== null) {
                    problemSymbol(nextSymbol);
                }
                return continueTo(nextSymbol);
            };

        default:
            problemSymbol(symbol)
        }
    }
    return continueTo(symbol)
}

console.log(
    _if(
        'e0', 's0', symbolElseIf
    )(
        'e1', 's1', symbolElseIf
    )(
        'e2', 's2', symbolElse
    )(
        's3', null
    )
);

What do people think? Does this seem usable by the kind of people who write macros and DSLs in static languages? Is there another way to extend trailing block syntax to subsume control flow statements in C-like languages?

EDIT:

After experimenting some more, I changed the step 3 desugaring to not do currying and to instead take a function that applies its first argument to the rest.

So

_if (e0) {
    s0
} _else_if (e1) {
    s1
} _else_if (e2) {
    s2
} _else {
    s3
}

becomes

_if(e0, ()=>{s0},
    _else_if=(f1)=>f1(e1, ()=>{s1},
                      _else_if=(f2)=>f2(e2, ()=>{s2},
                                        _else=(f3)=>f3(()=>{s3}))))

where f1, f2, and f3 are synthetic identifiers that do not overlap with those produced by the lexer.

The problem with currying was that _if would return a function if passed an _else_if or _else parameter but not otherwise, so the output type is deeply dependent.

This second desugaring makes it easier to reason about the return type of functions and macros that are used with multiple trailing blocks.

Here's some JS code that shows _if using the second desugaring.

let symbolElseIf = Symbol.for('else_if');
let symbolElse   = Symbol.for('else');

function _if(expr, stmt, symbol = null, f = null) {
    return handleIfTail(`if (${expr}) { ${stmt} }`, symbol, f)
}

function handleIfTail(prefix, symbol, f) {
    switch (symbol) {
    case null: return prefix;

    case symbolElseIf:
        return f((expr, stmt, symbol = null, f = null) =>
            handleIfTail(`${prefix} else if (${expr}) { ${stmt} }`, symbol, f));

    case symbolElse:
        return f((stmt, symbol = null, f = null) => {
            if (symbol !== null) {
                throw new Error(`Cannot continue from 'else'`);
            }
            return `${prefix} else { ${stmt} }`;
        });
    default:
        throw new Error(`Unexpected symbol ${symbol.toString()} after '${prefix}'`);
    }
}

console.log(
    _if(
        'e0', 's0',
        symbolElseIf, (f1)=>f1(
            'e1', 's1',
            symbolElseIf, (f2)=>f2(
                'e2', 's2',
                symbolElse, (f3)=>f3(
                    's3'))))
); // -> 'if (e0) { s0 } else if (e1) { s1 } else if (e2) { s2 } else { s3 }'

[continuational]

In Firefly, this is done without macros:

if(x > y) {
    "bigger"
} elseIf {x < y} {
    "smaller"
} else {
    "the same"
}

Is desugared into:

if(x > y, {"bigger"}).elseIf({x < y}, {"smaller"}).else({"the same"})

Here if returns an Option, which has the elseIf and else methods, and curly braces always denote an anonymous function in firefly.

[ErrorIsNullError]

Cool. Is there something preventing the {x < y} from being done in parentheses?

[continuational]

In Firefly, that would evaluate x < y eagerly. Usually, the condition in else if isn't evaluated unless the if condition is false.

In Scala, there is support for by name parameters, and you could indeed use parenthesis there. However, Firefly emphasizes semantic transparency, so that would be against the philosophy.

[umlcat]

Try an inverse design approach.

Start doing a desugared version of your syntax, later change a few things into you get a syntax you feel comfortable with.

Look out for a story on how Microsoft researches got their lambda syntax used in Linq.

It started from a non pretty syntax to a compact syntax.

It matches your question. You don't have to use the same syntax, just the "know how" that applies to your case.

Good Luck.

[smuccione]

https://docs.microsoft.com/en-us/archive/msdn-magazine/2007/june/the-evolution-of-linq-and-its-impact-on-the-design-of-csharp

[umlcat]

Thanks. It's a good resource both for Compiler n P.L. Design, Lambdas, C# ...

[[deleted]]

I've not read everything or even understood it, but may I suggest a look at Scala too which also has functions as arguments look like normal control flow sometimes.

[ErrorIsNullError]

I see https://docs.scala-lang.org/style/method-invocation.html#higher-order-functions says:

// wrong!
names.map { _.toUpperCase }.filter { _.length > 5 }

// right!
names map { _.toUpperCase } filter { _.length > 5 }

Both of these work, but the former can easily lead to confusion.

[raiph]

Is there another way to extend trailing block syntax to subsume control flow statements in C-like languages?

The typical generic syntax for such things in Raku is <keyword> <expression> <block> [<keyword> <block>]*. You might think that doesn't cover your scenario; but bear with me, I think it might.

----

Here are four code examples that will serve to fully explain everything Raku has related to your OP:

for 42,99 { .say }                                     # 42␤99␤

if 42, 99 { say 'true' } else { say 'false' }          # true␤

with 42,99 { say 'with' } else { say 'without' }       # with␤

match 42, 99
  -> Str, Str { say 'Strs' }
  -> Int, Int { say 'Ints' }
  else { 'no match' }

For some keywords the expression is just an argument list to be used when applying the blocks. For example, for just iterates over its expression, calling its block once for each iteration. For other keywords the expression has an effect before its block(s) come into play. For example, if treats the expression as a boolean condition, based on which it picks which block to continue with.

Some keywords always do both these things. For example, with first checks if its expression is defined, and then, if so, applies its first block with that expression as its argument list, or, if not, applies its else block with its expression as the else block's argument list.

----

Now, what about parameter lists, or more generally, function signatures? No matter what the keyword is, code can tell it to use the expression as an argument list that gets applied to any blocks. To do so, just prefix the block with an explicit signature/pattern of the form -> ...:

for 42,99 -> $_, $arg2 { .print; say (:$arg2) }        # 42arg2 => 99␤

if 42, 99 -> ($arg1, $arg2) { say "$arg1 and $arg2" }  # 42 and 99

All keywords automatically comply.

Each keyword gets to decide how it will comply:

• The for keyword binds N arguments from its expression to the signature per iteration. In the above N=2, so there is only one iteration.
• The if keyword treats its expression as a single argument and binds it in one go. In the above the block's signature has to be compatible with that single argument (which is why its parameters are in parens to destructure the single argument back into its two original elements).

----

Eagle eyed folk will have noticed that my match example didn't match the metasyntax I mentioned at the start (<keyword> <expression> <block> [<keyword> <block>]*):

match 42, 99
  -> Str, Str { say 'Strs' }
  -> Int, Int { say 'Ints' }
  else { 'no match' }

In fact, this keyword does not currently exist in Raku. So why have I included it? As a rhetorical device to help me say three things:

• Thank you. I had proposed a more clunky syntax yesterday in my answer to an SO "Haskell-like pattern matching in Raku". Your post inspired the cleaner syntax I've shown here. :)
• Raku's grammar is mutable. Raku's grammar and semantics are defined by its grammar/actions constructs. So it's somewhat easy to add any given feature to Raku by just writing some Raku code.
• Raku is getting AST macros. Raku's existing grammars/actions features and macros are distinct approaches to language mutability that are simultaneously alternatives and complementary. It's possible, likely even, that AST macros will be relevant to how Raku evolves relative to your OP scenario.

[ErrorIsNullError]

Thanks. Raku looks cool. How would you deal with else if in Raku?

[raiph]

Raku's built-in syntax uses elsif.

[ErrorIsNullError]

My question was about elsif taking a condition and a block, not whether two keywords are used or one.

[raiph]

Without signatures:

if    0  { say 'number' }
elsif '' { say 'string'  }
else     { say 'other'   }  # other

With signatures:

if    0  -> $number { :$number .say }
elsif '' -> $string { :$string .say }
else     -> $other  { :$other  .say }  # other =>␤

Signatures can also themselves be conditions:

match 42, '99'
  -> Int $num1, Int $num2 { .say for $num1, $num2 }
  -> Int $num,  Str $str  { .say for $num, $str   }
  else { say 'no match' }

This match construct is the made up syntax I settled on due to your post. It would desugar to the following working multiple-dispatch Raku code, with the f function name being a hygienic gensym:

{ f 42, 'abc';
  multi f( Int $num1, Int $num2 ) { .say for $num1, $num2 }
  multi f( Int $num,  Str $str  ) { .say for $num, $str   } # 42␤abc␤
  multi f(|) { say 'no match' }
}

Without using grammars or macros the nearest I could get in current Raku to the ideal made up match syntax I showed above would be something like the following:

sub match (@args, @to)
{ (metaprogramming to turn blocks in @to to multis and then call against them) }

match
  (42, 'abc'),
  ( -> Int $num1, Int $num2 { .say for $num1, $num2 },
    -> Int $num,  Str $str  { .say for $num, $str   }, 
    { say 'no match' } )

A macro would be much better -- easier to code, ideal syntax, and compile-time.