More examples added to fn:chain

[dnovatchev]

Added 6 more examples and tests
All are correctly executed.

[ndw]

This PR would be easier to review, I think, if you rebased it off of master. I'm seeing lots of spurious diffs.

[michaelhkay]

There are two differences between fn:compose (as proposed) and fn:chain.

1. fn:compose delivers a function, fn:chain applies the function. I would argue that the first option is better, because in most practical use cases I have seen, you want to apply the function more than once, to different inputs. Most often, you want to use it in a context where a function is required, for example as a callback to fn:filter. Clearly, however, there's no real difference in capability between the two designs.
2. fn:chain is able to include functions in the chain that have an arity other than one. However, if this is the case, then the immediately preceding function has to deliver the multiple arguments in the correct format, which means there is a strong dependency between the two functions: to build your chain of functions, you have to know a lot about the functions you are stringing together. I think that explains why, in all the examples here that use functions with arity >1, the function you are calling is actually statically known. I'm sure it's possible to construct examples where that's not the case, for example where the second function might be any binary operator on two numerics. But in those cases, I think you can achieve the required effect using fn:apply:

For example, the example chain(2, ($range, $double-all, op("*"))) can be expressed as 2 => compose($range, $double-all, array:append([], ?), apply(op("*"), ?)). That's a little bit longer [§], but I would argue that it's actually clearer because it makes the steps explicit: in particular there is no magic conversion between sequences and arrays.

It's this "magic conversion" that I dislike most about the fn:chain specification. Specifically, the rule:

if (function-arity($f) eq 1) then [ $x ]
    else if ($x instance of array(*)) then $x 
    else array { $x }

breaks the principle of substitutability. If a function can handle any sequence of items as input, then it shouldn't behave differently if that sequence of items happens to be a singleton array item.

[§] It would be nice if there were a function equivalent to array{$input} rather than the convoluted array:append([], ?). We could then write 2 => compose($range, $double-all, array:of-items#1, apply(op("*"), ?))

[ChristianGruen]

If I’m not wrong, all added examples could also be written with fn:compose. For example:

chain("a b c", (tokenize#1, count#1))
→ compose((tokenize#1, count#1))("a b c")

[dnovatchev]

This PR would be easier to review, I think, if you rebased it off of master. I'm seeing lots of spurious diffs.

Norm, what you are actually seeing is a whole new chapter appearing in the spec (and no, I didn't write it...) that is now hidden in the official FO 4 spec. due to someone's error.

The most likely suspect is probably PR 1856, which was accepted on our last week's meeting and then merged.

At present the official spec is missing completely chapter 6. Regular expressions . Please, have a look - screenshot taken on March 24th at 8:03AM PDT:

and here is what was hidden but should have been there - now seen as "part" of the current PR:

During my work on the current PR gradle signaled an error - unclosed <item> tag in content that is not touched by this PR.
I had to add this missing closing tag in order to make the build work, and this is how the whole chapter on Regular Expressions magically appeared in its right place.

And I expected you to say: Thank you ... 😄

Thus all these "spurious diffs" are the renumerations of all following sections, and they should have been caused by PR1856 if it didn't omit the end-tag.

To summarize: nothing is wrong in correcting the content to what it was supposed to be.

Thanks,
Dimitre

[ChristianGruen]

@dnovatchev
It seems your branch is some commits ahead of the current master branch. Did you try a rebase?

https://github.com/dnovatchev/qtspecs/tree/dn-examples

Next, your PR includes a PDF. Maybe it’s better to remove the document as long as you don’t want to have it included in the official repository.

[ndw]

I think we're struggling with some issues related to a broken PR getting merged last week.

But yes, @dnovatchev, please remove the PDF.

[dnovatchev]

Will submit it again after re-creating the branch.

[dnovatchev]

The new PR is: #1894