"fact(match)" is just making use of a generic feature: the "match" keyword in a pattern dictates that the body defines a sequence of sub-patterns to match at that position. An argument uses pattern syntax, so it works there, but it works in other situations, for example this contrived example:
f(x, y) =
match x:
{m, n} ->
match m:
<= 0 -> n + y
else -> m + n + y
n -> n + y
Can be rewritten:
f(match x, y) =
{match m, n} ->
<= 0 -> n + y
else -> m + n + y
n -> n + y
So you can match hierarchically like that (sorry if the example is strange, it's not supposed to mean anything).
I haven't seen this specifically, but I have seen other languages move common top level behaviors within functions into parameter lists.
Ruby, dart, coffescript allow setting of instance variables from the parameter list:
class Example
constructor: (@name) ->
# do stuff
class Example
constructor: (name) ->
@name = name
# do stuff
Jonathan Blow's language allows the `using` keyword in parameter list, which desugars in much the same way.
I'm personally not a big fan of using this technique for pattern matching, but its better than requiring explicit match blocks everywhere (like Scala and rust).
I haven't seen the feature elsewhere. The second example looks better to me (syntax highlighting helps) and reduces redundancy and indent, but I guess views may vary on this. Good to know!
If your goal is to reduce redundancy than I think a "lambda-case" syntax might be a better fit. As a bonus it also lets you use this feature on anonymous functions!
