Re: [xsl] Enabling extension to counting of instances

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

> What you do with that list could be anything, and in that context a
> higher-order function would be one of many things you might apply to the
> list, but the higher-order function isn't adding any unique value for
> extensibility.
>
> Or am I still missing something?

The HOF in this particular case automates a very frequently needed
task -- filtering a list -- and this is part of the solution of your
concrete problem.

In particular, you asked how to implement a solution, which will not
have hardcoded in itself what a "chapter" means. This is exactly
solved by using the f:filter() function.

Cheers,
Dimitre Novatchev.

On Fri, Jan 8, 2010 at 12:05 PM, Eliot Kimber <ekimber@xxxxxxxxxxxx> wrote:
> OK, I think I see what you're getting at: you're disconnecting the
> construction of a particular list (the first parameter to f:filter()) and
> the predicate applied to the list.
>
> I see that the value when the predicate can be meaningfully applied to
> unknown things.
>
> But you still have to construct the first parameter list, which in my case
> would be done via a list-type-specific mode. So unless I've missed
> something, that doesn't really change the extension mechanism: the business
> logic defines a particular type of list it needs (a list of things that are
> chapters) and names the mode for building that list and Toolkit plugins
> (added XSLT modules) provide templates in that mode to contribute members
to
> the list.
>
> What you do with that list could be anything, and in that context a
> higher-order function would be one of many things you might apply to the
> list, but the higher-order function isn't adding any unique value for
> extensibility.
>
> Or am I still missing something?
>
> Cheers,
>
> E.
>
> On 1/8/10 12:48 PM, "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> wrote:
>
>> On Fri, Jan 8, 2010 at 10:00 AM, Eliot Kimber <ekimber@xxxxxxxxxxxx>
wrote:
>>> I'm not sure how this satisfies my requirement for abitrary included XSLT
>>> modules to contribute to the filter function, but it's possible I'm not
>>> fully understanding the processing implications here since there's a bit
of
>>> indirection.
>>
>>
>> f:filter() takes two arguments: a sequence and a predicate (actually a
>> node, matched by a template that produces a boolean B :) B  )
>>
>> f:filter(1 to 10, f:compose(f:not(),
>> B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  f:flip(f:mod(),2)
>> B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B )
>> B  B  B  B  B )
>>
>>
>> takes the sequence 1 to 10 B (the integers 1,2,...,9,10)
>>
>> and a function that is the composition of:
>> B  B  B  1. getting the evenness of something (returns 0 if even, odd
otherwise)
>>
>> B  B  B  2. the not() function
>>
>> So, this composition is applied on any of the numbers 1 to 10 and a
>> sequence is returned that contains only these numbers, for which it:
>>
>> B  B  B  B  B  B  B  B  B  B  f:compose(f:not(),
>> B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  f:flip(f:mod(),2)
>> B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B )
>>
>> evaluates to true()
>>
>> Here we also use the fact that boolean(0) is false() and boolean(1) is
true.
>>
>> So, the 2nd argument of f:compose above is first evaluated and it
>> returns 0 for an even number and 1 for an odd number.
>>
>> Then, f:compose() applies the function not() to the result:
>>
>> not(0) is true(), not(1) is false.
>>
>> this means that the final result is true() for any even number in the
>> sequence. f:filter() returns a sequence of only those items of its 1st
>> argument, for which the result of applying the predicate (the 2nd
>> argument) is true(). As explained, this sequence will contain only the
>> even numbers.
>>
>> This is just one example, showing that f:filter() is a general
>> function that can be used with any sequence that we want to filter and
>> with any predicate we pass to be used for the filtering.
>>
>> In the case of the original problem, f:filter() will be passed a
>> sequence of elements and a predicate, which decides for any element if
>> it is a "chapter" or not.
>>
>> On every call to f:filter() the sequence of elements and the predicate
>> can be completely different and we don't know and don't care what
>> these might be (and actually, it is impossible to anticipate any such
>> pair of arguments that someone in the future may find to be
>> "meaningful").
>>
>>
>> This is the power of any Higher Order Function (HOF) -- it can use any
>> function-parameters without knowing their "meaning" as far as these
>> parameters are of the specified type (are functions with a
>> pre-specified signature). Thus HOFs are broadly applicable in huge,
>> unknown in advance problem areas.
>>
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com
>
>



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
I enjoy the massacre of ads. This sentence will slaughter ads without
a messy bloodbath.