`func (Tree func label)`

. There may be values of this type that do not contain trees. For example in the case of `RoseTree`

, `func`

is `[]`

, so `func (Tree func label)`

is `[RoseTree label]`

. As a result, you have a base in the form of the empty list. For instance, the expression `Tree 'X' (Forest [])`

denotes a rose tree with just a single node with label `'X'`

.
Note that even without such a base, the `Tree`

and `Forest`

types are not useless, since you can have infinite data structures.

For example, later when you define type List, there is a non-recursive constructor Nil, that allows to stop recursion. In case of Tree and Forest, the recursion seems to be infinite. ]]>

`reflClosure`

are the same, both equations of `reflClosure`

are considered. What exactly happens depends on the search strategy.
With *depth-first search*, Curry first evaluates `rel val1 val2`

from the first equation, and if this terminates, it takes the `success`

from the second equation. So if `rel val1 val2`

terminates with `success`

, then `reflClosure`

yields the value `success`

twice; if `rel val1 val2`

terminates with failure (meaning no result), then `reflClosure`

yields `success`

once. Only if `rel val1 val2`

does not terminate, `reflClosure`

does not terminate and yields no result.

With *breadth-first search*, both equations are processed concurrently. So the `success`

from the second equation will always be returned. Whether there will be another `success`

and whether `reflClosure`

will terminate depends on the behavior of `rel val1 val2`

.

Note that in the declarative semantics of Curry, there is nothing like falling back to the second equation, as there is in Haskell. If multiple equations of a function definition match, then all these equations are taken, and all are treated equally. It is just a specific search strategy, like depth-first search, that can make program execution not conform to this ideal semantics.

]]>