Syntactic sugaring proposals for Rholang

let

PLet. Proc2 ::= "let" [Binding] "in" "{" Proc3 "}";

BindingProcToPat. Binding ::= [Name] NameRemainder "<-" Proc3 ;

prototyped in PR #2055

see also RCHAIN-2641

The delimiter shown is ←; should it be =?

lambda

@ListOps!("foreach", 
          [1,2,3], 
          (x, ret) => {ret!(x+1)},
          *retCh)

...would be desugared to:

new lambda1 in {
    contract lambda1(x, ret) = { ret! (x+1)} |
    @ListOps!("foreach",
              [1,2,3],
              lambda1,
              *retCh)
}

The desugared version is what one has to write anyway in order to use tools like ListOps.

The expressiveness of Rholang will be hugely improved.

"contract methods" (technically they are not methods but I have no idea how to call them )

contract channel.methodName(a, b, c) | channel.methodName!(P, Q, R)

will translate to:

contract channel(@"methodName", a, b, c) | channel!("methodName", P, Q, R)

which translates to:

for (@"methodName", a, b, c <= channel)

contract varargs

contract myContract!(arg1, arg2, rest...) = { ... }

This would work nice with a tuple & list expansion 

@myChannel ! (+(1,2,3)) |
@myChannel ! (+[4,5,6])

...would be desugared to

@myChannel !(1,2,3) |
@myChannel !(4,5,6)

Such a syntax feature would allow us to write multi-arity contracts easier.

Also we could write decorator contracts that receive a message with any structure, do some work and then forward the original message to a lower level

Any nontrivial contract startw with setting up the dependencies like this and it looks pretty bad

rl!(`rho:id:exunyijimapk7z43g3bbr69awqdz54kyroj9q43jgu3dh567fxsftx`, *MakeMintCh) |
rl!(`rho:id:9dsr55z1js13x346yhhecx66ns486i3yqf6jafrd9p9hdrrbxjqmyu`, *LockboxCh) |
rl!(`rho:id:j6trahbxycumerwpr5qype7j43b7eqh8auebwsa9nn68if47gswh73`, *EitherCh) |
for(@(_, MakeMint) <- MakeMintCh; @(_, Lockbox) <- LockboxCh; @(_, Either) <- EitherCh) {

...

}

For this we will have to make the registry lookup as a special case of system processes but since it's used everywhere I don't see that as being a problem.