LC comment: describe the algorithm in functional terms too

These are personal comments, sent separately for the benefit of the 
tracking system

In addition to the procedural "Sequence" description in section 5.5, 
include a functional description of the algorithm.

Often times, a functional description is better suited for describing an 
algorithm to implementers, even if the eventual code will closely follow 
the sequence of steps given in section 5.5.

The process of translating the sequence description into functional 
terms will help improve the quality of the specification, make any 
algorithm errors or areas that are unclear or difficult to implement 
stand out better, resulting in a smoother call-for-implementations period.

Obviously, people actually implementing in a functional language 
(including XSLT/GRDDL) will find the beneficial as well.

What is a functional description? Any number of possible descriptions 
would qualify, but the essential constraints of a functional description 
* no side-effects or state
* no mutable variables

For example, a functional description be structured as a series of 
statements like this:
* For each <condition on node> produce a triple with <rule for subject> 
<rule for predicate> <rule for object>

I am personally interested in contributing on the list or wiki to flesh 
out the details of a functional description. I prefer a final result 
with normative weight, though.

Thanks, -m

Received on Monday, 31 March 2008 04:32:47 UTC