[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