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

[Ian MacLarty]

On Tue, Sep 29, 2009 at 5:50 PM, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> 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.
>

Thanks for clearing that up.

Ian.

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