[m-users.] use of cc_multi.

Sean Charles (emacstheviking) objitsu at gmail.com
Sat May 1 18:20:38 AEST 2021


Good morning Zoltan, and thank you again for a spot-on analysis.

I removed this line:
>> write_error(_, _, !_IO).
> 
and it was just fine as you pointed out it would be. Some habits are hard to shake, yes, I am used to Haskell too much at times and it clouds ones thinking of Mercury! The ‘:- type’ system I have found fairly easy to adjust to, that being very similar to Haskell, but the concept of instantiatedness trees took. a little longer to at least turn the light bulb on. I kind of get those now but probably not in as much detail as I would like… I tend to wait until the compiler shouts at me loud enough, a bit like being married I guess.

I have spent one hour over breakfast reading parser.m, I read as much of the code as I can when I can but it’s always a choice between reading code or writing your own code and sometimes the urge to learn, burn and churn overrides logic and common sense. :)

I continue to learn...
Sean


> I would bet that this line is the problem. The other clauses
> are effectively a switch on the first argument, which means
> at most one of them is applicable, but this clause will be applicable
> regardless of what the value of the first argument is.
> 
> My guess is that you intended this clause to be a Haskell-style
> catchall, to apply in cases where the first argument's value
> is not handled by either of the clauses above. Mercury does not
> work like that. In Mercury, the right thing to do is to *tell*
> the compiler that this clause applies *only* when the first arg
> is not one one of plain, simple, json or xml. You can do that
> like this:
> 
> write_error(ErrorFormat, _, !IO) :-
>  ( ErrorFormat = otherformat1
>  ; ErrorFormat = otherformat2
>  ...
>  ; ErrorFormat = otherformatN
>  ).
> 
> This is more work up front than a catchall, but much better
> in the long run, because if later someone adds a new errorformat,
> they get an error that tells them they have to update this code.
> 
> By the way, if you want to know how such code is formatted
> by the Mercury project, have a look at check_for_bad_token
> in parser.m in the Mercury standard library.
> 
> Zoltan.



More information about the users mailing list