Bonjour,

Quoting Stéphane Glondu <steph@glondu.net>:
> I don't really understand what you are doing: why do you generate a list
> of continuations instead of a single one?

Reordering the continuations to continue the computation in an other  
branch than the deepest try ... fail is a classical technique in  
combinatorial optimization. The way you order your continuations  
defines a "node ordering strategy", most usual being :
- stack -> depth first search
- queue -> limited discrepancy search
- priority queue -> best first search

> Don't you want a kind of lazy list?

I first wrote a code that solves the problem completely.
Then I modified the code to handle continuations of the form (unit ->  
somthing)
Then I replaced (unit -> something) with a lazy list
Finally I kept the list of continuations but send it back by function  
return instead of an exception [And type inference DOES work in that  
case !]

I am "complaining" because the compile DOES infer types within  
exceptions but does not allow you to let him fix the type the way he  
needs. It only says "It is not what I was expecting, so your function  
won't compile, sorry".

As far as I understand the reason is to avoid polymorphic exceptions  
but this could have been done just forbidding the final result to be  
polymorphic or typechecking and not compiling, or giving me a way to  
just typecheck without creating the value.

> Does this code really do what you expect?

Reasonably

>> lets try ...
>
> Is this the end of your mail?

Unless you want a complete log of everything I tried when developping  
that code...

         Diego Olivier