[m-users.] Warning: this disjunct will never have any solutions.
Sean Charles (emacstheviking)
objitsu at gmail.com
Fri May 28 06:47:29 AEST 2021
Yes, Zoltan, right again.
I guess I just need more time to play with Mercury and get more flying time with it.
The exception thing makes me itchy to be honest… I need to rethink my whole approach to it I guess. I don’t want to be writing dirty code.
And tonight the determinism messages are driving me insane! However, the code I have written so far for the REPL mode is absolutely perfectly clean and works and so I am encouraged to continue.
Thanks again.
Sean.
> On 27 May 2021, at 21:41, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> 2021-05-28 06:31 GMT+10:00 "Sean Charles (emacstheviking)" <objitsu at gmail.com>:
>> Is it safe to ignore this given I know why …my parsing code reaches a point where it knows a syntax error has been detected:
>>
>> :- pred s_exp(anode::out, latok::in, latok::out) is nondet.
>> s_exp(X) -->
>> (
>> ( op(_P) ->
>> expression_body(X),
>> ( cp(_)
>> ; error_pos(P),
>> {throw(syntax_error(P, expected_close_paren))}
>> )
>> ;
>> error_pos(P),
>> {throw(syntax_error(P, expected_open_paren))}
>> )
>> ).
>>
>> I can see that throwing the exception does mean there can be no solution…I expect there is a compiler switch to silence it but I don’t like doing things like that… is there a Mercury-esque technique/approach etc that I have not yet learned about?
>
> If op(_P) and expression_body(X) succeed, the following disjunction *will* throw
> an exception after all the solutions of cp(_) have been exhausted. To me, that looks like
> a genuine error to be fixed, not one to silence.
>
> And since you are asking about Mercury-esque approaches: such an approach
> would return a value that contains either the result of a successful computation
> or an error description, as e.g. io.result does. It would *not* use exceptions.
>
> Zoltan.
More information about the users
mailing list