Take the following script:
function tester($foo, $bar) { $foo; “Bar:” + $bar.Name }
$f = [System.Net.Sockets.TcpListener]80
$b = get-process msh tester $f
$b
“Wonky call:”
tester($f,$b)
Both the last two lines of the script are valid (as in, the parser does not throw an error), but give completely different results:
Server LocalEndpoint
------ -------------
System.Net.Sockets.Socket 0.0.0.0:80
Bar: msh
Wonky call:
System.Net.Sockets.Socket 0.0.0.0:80
The second invocation does not result in displaying $bar.Name. Maybe there’s some secret use of func() syntax (which would explain why the parser does not throw an error) that I’m missing here (actually, what’s happening is that the function gets the entire contents of the paren as a list). To be really symmetric with other languages, Monad should really switch func arg1 arg2 and func(arg1,arg2) as the latter is commonly known. Though one reason for not doing it is for dynamic creation and execution of functions, in which case it might be slightly easier to call functions if you don’t have to bother with parens. The real reason is likely that the current behaviour brings consistency with how cmdlets are treated (and scritps), after all you don’t call a cmdlet like this: some-cmdlet(param1,param2). In the end the current Monad solution makes sense if you look at the big picture, but you need to realize the difference between using parens and not. Otherwise you might run into some hair pulling sessions with your script.
Oh btw, you can see wonky behavior #1 as part of this script as well. So, like I’ve been telling folks on the Exchange team who are busy writing scripts for demos and testing, make sure you check your syntax before you file a bug 
.