I'm the author. I have just released the first alpha. I've been programming Scheme for close to a decade now after about the same amount of time using Perl, and I've written this to be able to like programming Perl 5 again, when I have reason to use it. It works pretty well for me for that purpose, although I guess I'm biased.
I guess the layout is pretty old-fashioned, and I might have too much text; I'm trying to cater to people who are not used to functional programming yet, but I'm not sure I'm achieving that. I guess it's also a rather difficult sell when many Perlers prefer to use the upcoming Perl 6 instead, and others decide to leave for a more proper functional programming language implementation.
I'm rather proud that I've managed to base lazy sequences on lazily evaluated linked lists, i.e. based on purely functional principles down to the cells, instead of using iterators as many function libraries for sequences for non-functional languages (like JavaScript or C#) do. Not sure how much it matters in practice, but at least you can write lazy sequences with this the same way you do in Haskell (see fibs and primes examples).
There are some good points doing FP in Perl 5 compared to some other non-FP languages (you can do optimized tail-calls pretty cleanly), and some bad points (you have to care about memory handling in some places). I've got ideas how to improve on both fronts but that will depend on the uptake of the project.
Another interesting book in this same functional perl genre is Higher Order Perl, available free online here: http://hop.perl.plover.com/
Edit: I see now that it was mentioned on the page. Consider this comment another recommendation then. If you are interested in perl and functional programming, check this book out!
General question: what are some pros and cons of Perl compared to other languages like Python, Ruby, Java, Clojure, Haskell? What makes Perl unique and people so enthusiastic about it?
It reifies the process of munging and pattern matching on text streams in a way few other dynamic languages do. Perl 6 particularly so with grammars (similar to lex) as a first-class construct.
It's more appropriate to compare it to SNOBOL and AWK.
For me the enthusiastic part is that it's the first language I used for a lot of stuff. My brain knows how to work with it. I know what I get. Perl is also a constant, it doesn't change a lot and my scripts from almost two decades ago still work. Also, it's part of the basic install of any common Linux distribution.
Dealing with a reference-counting GC is a bit of a nuisance when occasionally having to help it along manually, after getting used to a real GC, but it can also be beneficial: memory usage is deterministic and rather low.
Perl is also slow handling data structures compared to languages like Java, Clojure or Haskell, unless you implement those / the bottlenecks in C, which functional-perl currently does not do.
Perl is very hacky, in both the good and bad senses: it's not a simple and clean language or ecosystem (kind of the anti-thesis of Scheme), but it's also very malleable: core perl allows you to do a lot of things for which you would need macros or similar features (I still don't know how Ruby works in this regard) in other languages, and various approaches to extend it exist nowadays (e.g. you want something nicer than "sub { my ($x)=@_; ... }"? Today you can write a module that allows you to write "fun ($x) { ... }" pretty cleanly (also someone implemented[1] one for this example already)). Also, I've been positively surprised to find good hackers in the Perl community when I returned; perhaps that's correlated.
It takes five minutes of a good tutorial to understand what references are and how they work. Yet it's not rare to see so called senior developers still failing to use them properly and introducing bugs because of it.
I too think it's a fair point; Perl tends to have too many syntactical features that take up processing power in the brain: JavaScript style foo.bar.baz is just lower overhead than $foo->{bar}{baz} or $foo->{bar}->{baz} or $$foo{bar}{baz} or if foo is a hash variable, $foo{bar}{baz} or variants. The brain has to filter out whether the first variable holds a reference or is a hash variable, then has two different dereference syntaxes to choose from (ok JavaScript has two variants, too), then later '->' are optional. You get used to it, but it still draws some attention away from the more interesting parts of a program.
In a way my project improves a bit over this, since you're often not using Perl base data structures directly anymore; OTOH of course that means writing out a function or method call, and while this is more universal (which I like) it also uses more space to type. Also, sigils are getting more pointless when using libraries (I usually don't use % and @ anymore, always references, the good part of which is that this is giving a bit more consistency).
I would argue that it less adds cognitive load than it shifts that load from other portions of the language. Dealing with references makes some operations (such as telling if two variables contain the same data in memory) very easy, while making others (such as top level access to hash/array items) harder. I think that it makes some advanced operations easier to understand at a glance and reason about at the expense of those unfamiliar with the language (or references in general).
I guess the layout is pretty old-fashioned, and I might have too much text; I'm trying to cater to people who are not used to functional programming yet, but I'm not sure I'm achieving that. I guess it's also a rather difficult sell when many Perlers prefer to use the upcoming Perl 6 instead, and others decide to leave for a more proper functional programming language implementation.
I'm rather proud that I've managed to base lazy sequences on lazily evaluated linked lists, i.e. based on purely functional principles down to the cells, instead of using iterators as many function libraries for sequences for non-functional languages (like JavaScript or C#) do. Not sure how much it matters in practice, but at least you can write lazy sequences with this the same way you do in Haskell (see fibs and primes examples).
There are some good points doing FP in Perl 5 compared to some other non-FP languages (you can do optimized tail-calls pretty cleanly), and some bad points (you have to care about memory handling in some places). I've got ideas how to improve on both fronts but that will depend on the uptake of the project.