# Preview of functional programming syntax for futile.paradigm 2.1

July 9, 2012
By

(This article was first published on Cartesian Faith » R, and kindly contributed to R-bloggers)

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.

To leave a comment for the author, please follow the link and comment on their blog: Cartesian Faith » R.

R-bloggers.com offers daily e-mail updates about R news and tutorials on topics such as: Data science, Big Data, R jobs, visualization (ggplot2, Boxplots, maps, animation), programming (RStudio, Sweave, LaTeX, SQL, Eclipse, git, hadoop, Web Scraping) statistics (regression, PCA, time series, trading) and more...

If you got this far, why not subscribe for updates from the site? Choose your flavor: e-mail, twitter, RSS, or facebook...

Comments are closed.

## Sponsors

Contact us if you wish to help support R-bloggers, and place your banner here.

# Never miss an update! Subscribe to R-bloggers to receive e-mails with the latest R posts.(You will not see this message again.)

Click here to close (This popup will not appear again)