This section can be skipped by the casual reader.
In this section we discuss the rationale of Noos methods being also feature
terms. In 
-calculus, functions have the property of also being
values--that is to say functions-as-values can be manipulated by
functions--passed as parameters, returned by functions, etc. In languages
like Lisp or Scheme closures--a function plus the set of bindings
referenced by that function--are first class objects that can be
manipulated by other functions. Closures can be returned by functions,
passed as parameters--but they are opaque. A closure can be
understood as a value that packages a function and a representation of
state
. However, there is no way any
external program is able to inspect any variable binding inside a closure.
A closure can be passed around and applied (evaluated)--but nothing else.
We say closures are opaque because of this property.
For instance, if we consider a closure where first parameter of a
function in the closure, say x, is bound to 3, there is no any external
function can obtain the value of x. What is needed to access x is to
have a function defined in such that ``captures'' x and returns the value
of x. Even so, in order to update that x variable, there has to be
another function defined that ``captures'' x and performs an assignment
on x. In fact, with these basic constructs on closure handling is easy
to provide object-oriented extensions of Lisp and Scheme.
On the other hand, Noos methods are also feature terms, and they are not only first-class objects (values) but they are inspectable to external methods. Since method parameters are passed by names (feature names), we can have path references to those features. We can say thus that Noos methods are transparent. For instance, if we define Wet-Causal-Expl-Home as a refinement of wet-causal-expl of Example 2.9 as below, we can have references to the features of Wet-Causal-Expl-Home like those to any other feature term.
Notice that in this example the features place and effect of the method can be referenced
Why we need methods to be transparent? The reason is to be able to perform
introspective tasks, i. e. to perform forms of inference that need to
inspect and reason about other methods and how they have been used to solve
particular tasks. An example of using introspection is a form of
compilative learning--also called explanation-based learning (EBL). A
learning that performs EBL builds a more efficient and compact method
examining the proof structure of the methods that were used to
solve a particular problem. Such a method requires the introspective
capability of accessing and manipulating the terms and formulae in the proof
structure. Consequently, integrating some forms of learning techniques--a
main goal in Noos language design--requires some way of introspection that
in Noos is achieved by the methods themselves being feature terms. In
fact, also other reflective capabilities are needed, like the method
and task constructs. The constructs method and task
allow to access the method pertaining to a specific feature. For instance,
in order to access the place feature of the wet-causal-expl
method used in the ground-status task of Example 2.10
we can use these constructs to build up a reflective reference as follows:
(>> place of (method of (task ground-status of (>> house of John))
These and other reflective capabilities are explained in
Chapter 4.