I’m developing a streamlined syntax for the next release of futile.paradigm. While this version is backwards compatible, it introduces a cleaner syntax for functional programming. The noteworthy improvements are a more natural pattern matching syntax, integrated (optional) type checking in functions, and a cleaner syntax for type constructors. Here are some examples.

Fibonacci Sequence

This sequence is a good example of a recursive definition.

fib(0) %as% 1
fib(1) %as% 1
fib(n) %as% { fib(n-1) + fib(n-2) }

Kronecker Delta

The unit impulse is a common multipart function.

delta.k(0) %as% 1
delta.k(x) %as% 0

Inverse

This example is a little contrived but is illustrative of the type checking you can perform.

inverse(matrix x) %as% solve(x)
inverse(numeric x) %as% x^-1

Multiline Functions

Clearly not all functions are one liners, so we support multiline definitions as well.

fn(x, y) %as% {
  z <- x + y
  z * 2
}

Type Constructors

The syntax for type constructors in previous versions of futile.paradigm is a little klunky. With f.p 2.1 the definition for type constructors can collapse into the same syntax as regular. Creating these types could thus look like this:

Portfolio(x) %as% {
  returns <- get.returns(x)
  list(returns=returns)
}

p <- Portfolio(my.prices)

The one caveat is that this may break the %isa% function, although with direct type checking it may not be needed anymore.

Notes

More complicated expressions should continue to use the %when% and %also% syntax, although the new syntax should cover ~85% of use cases (based on my own usage).

At times the ellipsis would be useful in multipart functions. I haven’t come up with a way of integrating it that I’m satisfied with. It really comes down to making sure the syntax and interpretation is deterministic. The other problem is that the extra tests involved with the ellipsis could impact performance. So this one is a work in progress.

Default values are another convenience that I’m working out how to integrate. While I am a bid advocate of functional syntax, I think we should leverage the features that R has to offer. Again, this comes down to a deterministic evaluation that has good performance.

I’m toying around with some ideas for optimizations, particularly for tail recursion, but this is still in the idea stage.

Feel free to send me suggestions on syntax as I have not implemented this yet although I plan to in the next week or so. Any test cases would be great as well.