[m-users.] Determinism issue with parser
Zoltan Somogyi
zoltan.somogyi at runbox.com
Mon Jul 5 03:34:16 AEST 2021
2021-07-05 03:21 GMT+10:00 "Volker Wysk" <post at volker-wysk.de>:
> The compiler told me that repeatmax0 is nondet. The implementation is
> simple:
>
>
> repeat0(_, []) --> [].
>
> repeat0(Pars, Values) -->
> { Values = [Val|Values1] },
> Pars(Val),
> repeat0(Pars, Values1).
>
> repeatmax0(Pars, Values) -->
> repeat0(Pars, Values), % XXX
> ( if not Pars(_)
> then []
> else end
> ).
This is nondet because the compiler can't see any reason
why the second and third clauses could not both generate
a solution.
> Taking your hint about disambiguation code, I was able to reformulate the
> repeatmax0 predicate such that, repeatmax0 becomes deterministic for a
> deterministic input parser:
>
>
> :- mode repeatmax0(pred(out, in, out) is det, out, in, out) is det.
>
> repeatmax0(Pars, Values) -->
> ( if Pars(Val)
> then { Values = [Val|Vals] },
> repeatmax0(Pars, Vals)
> else { Values = [] }
> ).
>
>
> I'm still not sure what you mean by "disambiguation code", though.
I meant any code that tells the compiler that there will be only one solution
even though its old version would be able to generate more than one solution
as far as the compiler is concerned.
Your code immediately above does this: by replacing the original second
and third clauses (an implicit disjunction) with an if-then-else, you told the compiler
that there will be a solution from either then then-part or the else-part, BUT NOT BOTH.
So it seems you understood my hint sufficiently well, even if you did not think so :-)
Zoltan.
More information about the users
mailing list