`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.

]]>`rel val1 val2`

and failing if `rel`

is not reflexive?
reflClosure :: Relation val -> Relation val reflClosure rel val1 val2 = rel val1 val2 reflClosure rel val val = success

Or, because failure corresponds to partiality, it will fall back to the next branch?

]]>length $ splits $ replicate 1000000 M

This should give you the result `1000001`

quite quickly.

Now try this:

length $ splits' $ replicate 1000000 M

I wasn’t able to get a result within a reasonable amount of time.

The problem with `split'`

lies in the use of `inits`

. The `inits`

function is implemented as follows:

inits :: [a] -> [[a]] inits xs = [] : case xs of [] -> [] x : xs' -> map (x : ) (inits xs')

Note that the recursive application of `inits`

is under a `map`

. So the suffix of an expression `inits [x_1,x_2,…,x_n]`

that starts at an index is defined by a nested application of `map`

of depth :

`map (x_1 : ) (map (x_2 : ) (…(map (x_i : ) […])…))`

To detect that the result of an expression `map f xs`

is non-empty, we have to detect that `xs`

is non-empty. So to detect that the above suffix is non-empty, we need to walk through the layers of `map`

s, which takes time.

This means that to fetch the -th element of `inits xs`

, we need

time.

The implementation of `split`

doesn’t suffer from this problem, since it creates prefixes by a single application of `map`

, and computes every single prefix independently.

`split`

more efficient than `split'`

?? I was unable to exhibit any difference between the two (Criterion used).
Thank you!

]]>`stringPrefix`

function returns a `Maybe`

value, since it needs to signal whether the given list starts with the given prefix or not. In the `replace`

function, I have already ensured that it does; so it is simpler to use the solution with `drop`

and `length`

, where I do not have to get rid of the `Maybe`

.
]]>