Re: [m-users.] Free and Ground in the same error line?

I rewrote it like this, could it be any leaner? Asking in case I am not as good as I can be yet :D !

    384 get_class_superclass(Class, Super, !X) :-
    385     ( if !.X = [ tk(Cp, Cb) | Rest ] then
    386         Class = ps(Cp, Cb),
    387         Super = no,
    388         !:X   = Rest
    389     else if !.X = [ sexp(_, [ tk(Cp, Cb), tk(Sp, Sb) ]) | Rest ] then
    390         Class = ps(Cp, Cb),
    391         Super = yes(ps(Sp, Sb)),
    392         !:X   = Rest
    393     else
    394         fail
    395     ).

I mean, it's fine but in the manual, 2.13 DCG-rules it says "As a matter of style, we recommend that in future DCG notation be reserved for writing parsers and sequence generators, and that state variable syntax be used for passing state threads."

And I am writing a parser system so I figured it was permissible to use DGC form. I have a lot more DCG code in my project... it ain't broke, don't fix it!



> On 28 Oct 2023, at 12:05, Zoltan Somogyi <[email protected]> wrote:
> 
> 
> On 2023-10-28 21:53 +11:00 AEDT, "Volker Wysk" <[email protected]> wrote:
>> I have the impression that the compiler often gives complicated error
>> messages for stupid errors...
> 
> The two main factors influencing whether the compiler will have a direct,
> specific error message for a class of errors are
> 
> - how frequent that class of errors appears to be, and
> - how difficult that class of errors is to isolate from other classes.
> 
> It is a sad fact of life that the people judging the frequency
> of error classes are the compiler developers. Since their errors
> have a different frequency distribution from other language users,
> the work they (we) put into improving error messages usually
> benefits us more than it benefits general users. That said, we of course
> do try to improve messages even for errors we don't encounter
> ourselves. (For example, I wouldn't encounter this bug, because
> I stopped using DCGs ages ago.) Of course, this does require that
> such problems be brought to our attention. That usually works;
> for example, I extended the error message mmc generates
> for references to undefined types, predicates etc with "did you mean"
> suggestions (such as "circle" for "cirle") a few days after the m-users
> thread about that error.
> 
> So if you get a complicated error message for an error, stupid or not,
> you know what to do.
> 
> Zoltan.

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users