@Paul: Sure, here it is. I hope it’s useful to you.

  function quickcheck (args, test, config)

  {

    if (!config) config = new Config(100, 1000);

    var p = new Prop("", args, test);

    var res = runProp(config, p);

    var passed = res.status === "pass";

    var msg = res.status

    if (res.status === "fail") msg += " on " + QUnit.jsDump.parse(res.failedCase);

    msg += " (" + res.counts.pass + " passed, " + res.counts.invalid + " invalid)";

    ok(passed, msg);

  }

Thanks

Very sharp, this is indeed a typo! Thanks for this notification. In this example the `deep’ combinator can only take one argument.

Another way to write it down is to put an additional seq inside the `deep’:
var toc = mkElem(“ul”)(seq(deep(seq(isHeader, mkElem(“li”))(self))));

seems to be
var toc = mkElem(“ul”)(seq(deep(isHeader), mkElem(“li”)(self)));

Yes, this is exactly what we have done! Because the underlying semantics are very clean rebuilding it was very easy. These combinators for themselves have no big advantage over XPath of course, but now that we have our own implementation in JavaScript extending (in multiple dimensions) becomes very easy.

The reason for this post was showing other programmers that looking at the semantics of an existing system can change it from some black box magic into something simple and understandable. There was never an intention to present something that on itself could ever supersede XPath/XSLT.

Thanks for keeping XSLT functional!

This of course was always one of the major justifications for making XSLT/XPath a functional language.

It seems to me that all you have done is to strip off the syntactic sugar offered by the XPath syntax and expose the underlying functional semantics.

Note that you hardly have to write any code to use regular: the instances can be derived using TH (!).

Max

<user>

  <name>Erik</name>

  <email>erik@typlab.com</email>

  <admin>true</admin>

</user>