One interesting idea (for JS) is defining functions as pattern matches on the arguments. Here's a factorial from the docs:

    >>> var factorial = wu.match(
    ...   [ 0 ],      1,
    ...   [ Number ], function (n) { return n * factorial(n - 1); }
    ... );
    >>> factorial(5);
    120

I played with the same idea a couple of years ago and published a library for it: * http://www.bramstein.com/projects/jfun/ * http://www.bramstein.com/articles/pattern-matching.html * http://www.bramstein.com/articles/advanced-pattern-matching....

Although the implementation works great, I couldn't get past the (obvious) syntax issues and never actually used it in production code. It was an interesting experiment though, especially when combined with Sjoerd Visscher's algebraic data type library (http://w3future.com/weblog/stories/2008/06/16/adtinjs.xml).

That took me a bit to understand what is going on, but now that I see it it really is cool.

Each line (e.g. [ 0 ], 1,) represents something similar to (key,value) pairs. So, in the first example any input that matches the array ([0]) (or [1,293,592] for that matter) would return the "value", or in this case "1".

It gets better with the following line, if the input matches a ([Number]) then it returns "function (n) { return n * factorial(n-1); }", a common recursive algorithm for finding a factorial.

Really, a nice looking framework all around.

Yep, it's pretty neat. If you're familiar with haskell (I'm not sure if haskell invented it, but it's probably the most well-known example) this will be familiar to you. For example, factorial could be written as:

fac 0 = 1

fac n = n * fac(n-1)

Other languages with pattern matching include Prolog* , ML, and Erlang. (If I'm not mistaken, it originated with SNOBOL.) Awk also uses regular expression matching toward similar ends, but it's like comparing REs to a full parser.

* Prolog has unification, actually, which is more powerful than pattern matching. Instead of trying to match a value against a list of patterns, it tries to match two (or more) potentially partially-defined values against each other.

Pattern matching is one of my favorite language features. PM-based code is usually quite straightforward to read (especially compared to a jumble of nested 'if's!), and can be compiled to efficient decision trees. It also works well with both static typing (checking full coverage of ML-style variant types) and dynamic typing (such as with Erlang's receive). The closest thing most OO languages have is polymorphism, which tends to break up the pattern table into lots of little scattered ones (unless the language has multimethods), making it harder to see the big picture.

Ok, now that is very neat.

How many function objects are created to generate that result? From a certain point of view, that is interesting too of course.

Without looking at the source: it could either generate a decision tree made of nested ifs and case statements (or the CPS equivalent), or it could just do a naive linear search over each list element. That's probably good enough until you have long lists of alternatives or structural matching against whole trees.

I have a quick hack of a Lua library that does pattern matching with linear search. Whenever I get around to making it actually do analysis and compile search functions, I'll put it on github. (The patterns can have variable captures in them, too.)

Here is the relevant code: http://github.com/fitzgen/wu.js/blob/master/lib/wu.js#L574

I'd be very interested to see some real-world cases for lazy sequences in context of client-side JavaScript interpretation.

The "Why?" section doesn't seem to have any information in the docs.

> I'd be very interested to see some real-world cases for lazy sequences in context of client-side JavaScript interpretation.

Please remember that JS is no longer just client-side stuff. Node.js, and other implementations have become quite popular in some circles for doing server side things.

> Please remember ...

JavaScript runs on the server side? ;-)

Quote from wu.js site:

"Works great in the browser".

Hence my genuine interest in understanding the not so obvious real-world cases for lazy-seq and client-side programming.

I've had a bit of the same issue.. I wrote a similar library a while back, and was hard pressed to find a situation in which JavaScript's method invocation overhead didn't overshadow much of the benefit of the lazy execution.

They're fun to write though, it'd be interesting to see if there are any useful applications.

Aware of the "Why" section issue, however don't have time for a fix right now, I'm about to head off to a final exam.

I will be trying to get a "real world" and practical example that is a little more in depth out soon, but my first goal was total API documentation coverage.

Thanks for the interest,

Nick

That dead link has been removed now.

Hey everyone, this is my baby and I would love to get some feedback.

If you have any questions, don't hesitate to ask anything (but I might disappear for a couple hours because I have a final coming up).

Thanks!

(Back from my final now (it went well)).

Just quietly, I've written a library that provides lazy sequences as MooTools Classes if anyone is that way inclined.

http://github.com/sharkbrainguy/sequences.js

Some basic examples:

http://jsfiddle.net/Zh7pR/

It does suffer from the whole "what's the point" problem.

Killer name.

Thanks :)

If anyone isn't aware, it is named after the infamous Wu-Tang Clan: http://www.youtube.com/watch?v=0OEcZqG9xnE

you can sell wu wear

the part I loved the most: that ain't nuthin' ta f*ck wit.

I like the idea of these functional JS libraries but I'm always concerned about the performance hit.

underscore.js provides alot of functional (not lazy) tools with solid performance.

http://documentcloud.github.com/underscore/

Check out the benchmarks:

http://documentcloud.github.com/underscore/test/test.html