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(_at_)gmail(_dot_)com> wrote:
On Fri, Jan 8, 2010 at 10:00 AM, Eliot Kimber
<ekimber(_at_)reallysi(_dot_)com> 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 :) )
f:filter(1 to 10, f:compose(f:not(),
f:flip(f:mod(),2)
)
)
takes the sequence 1 to 10 (the integers 1,2,...,9,10)
and a function that is the composition of:
1. getting the evenness of something (returns 0 if even, odd otherwise)
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:
f:compose(f:not(),
f:flip(f:mod(),2)
)
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--