[m-rev.] Re: for review: parsing_utils improvements

[Zoltan Somogyi]

On 29-Sep-2009, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> But how is that different from what is happening in parse/4?

Not at all; that should be cc_multi as well.

> semantics of parse/3 as:
> 
> parse(Input, Parser, Result) <=>
>     new_src_and_ps(Str, Src, PS0),
>     ( Parser(Src, Val, PS0, _), Result = ok(Val)
>     ; not Parser(Src, _, PS0, _), Result = error(_, _, _)
>     )

Yes, but *which* error would Result be bound to?

> So declaratively, if Parser(Src, _, PS0, _) is false, Result will be
> error/3, but the arguments to error/3 are unspecified.  This looks a
> lot like the declarative semantics of try.  So surely parse/3 should
> be cc_multi too?

Yes.

> But then this use of cc_multi doesn't seem to fit the notion of
> determinism described in the reference manual, which only talks about
> how many times a *procedure* should *succeed* (an operational
> property).

If it can succeed exactly once both declaratively and operationally,
it is det. If it can succeed exactly once operationally but more times
declaratively, it is cc_multi.

> p([_]).
> 
> This compiles.  It succeeds only once, but declaratively it has many
> solutions (the interpretation includes many ground atoms).  If try is
> cc_multi then why isn't p multi?

Because even declaratively, it has a single most general solution,
to wit, HeadVar_1 = [X] for some X. This solution is unique up to
variable renaming.

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