[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Enabling extension to counting of instances
> 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|