[m-rev.] for review: try goals

[Julien Fischer]

On Thu, 19 Feb 2009, Peter Wang wrote:

>>>>
>>>> Is the @samp{io} parameter really needed at all?  Can't the compiler
>>>> just infer it by the use of I/O state in @var{Goal}?
>>>
>>> It can.  I originally thought it might make the implementation hard, but
>>> actually it shouldn't make much difference.  I can change it later if
>>> people
>>> think it's a good idea.  The only objection I might have is that it break
>>> the
>>> parallel with the other proposed try parameters, but those are extremely
>>> uncommon whereas try_io is even more common than plain try.
>>
>> The only other proposed try parameters I can think of are store/0 and
>> the STM state - it ought to be able to infer both of those as well.
>> (Certainly the latter.)
>
> That leaves only "try [all(Solutions)]", which actually needs to be
> "try [all(Output, Solutions)]" so we know what to collect.  On the other
> hand it's not common enough to provide special syntax, and I don't feel
> like implementing it ;-)

try [all(Solutions)] doesn't seem necessary; the existing try_all
predicate does not allow the user to handle exceptions directly anyway.
It only tells you that an exceptions was thrown and if so what the
exception value is.

> Ian had an idea to supply the name of the "try" predicate yourself;
> something like "try [pred(foo.bar)]" I suppose.  You could use the try
> syntax to enclose blocks of code which need to be run in a particular context,
> e.g. a database transaction.  The details are not worked out yet but this
> could be generally useful so I think the parameter list should stay, even if
> it'll always be empty right now.
>
>>
>> Could you please post an updated version of just the reference manual
>> changes.
>>
>
> Below.
>
> [also]
>> The reference manual should also state an purity restrictions on
>> @var{Goal}, @var{ThenGoal}, ... etc.
>
> There are no purity restrictions.  Should there be?

No, I was just wondering as the closures passed to the predicates
in the exception module are pure.

> Previously if Goal was non-pure, once it got moved into a lambda
> the call to try* would still be pure.  I've now wrapped the try* call
> into a promise_semipure/promise_impure scope to match the purity of Goal.

This seems like a definite improvement since the exception module
didn't define impure versions at all.

> +The declarative semantics of a try goal is:
> +
> + at example
> +        (try [] Goal
> +         then Then
> +         else Else
> +         catch CP1 -> CG1
> +         catch CG2 -> CG2
> +         ...
> +         catch_any CAV -> CAG
> +        )  <=>
> +                (
> +                        Goal, Then
> +                ;
> +                        not Goal, Else
> +                ;
> +                        some [Excp]
> +                        ( Excp = CP1 -> CG1
> +                        ; Excp = CP2 -> CG2
> +                        ; ...
> +                        ; Excp = CAV, CAG
> +                        )
> +                ).
> + at end example
> +
> +If no @samp{else} branch is present, let @samp{Else = fail}.
> +If no @samp{catch_any} branch is present, let @samp{CAG = fail}.

The semantics of the I/O version should also be discussed.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------