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

Am Samstag, dem 28.10.2023 um 13:04 +0100 schrieb Sean Charles
(emacstheviking):
> 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     ).

Looks good to me.

> 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!

A DCG rule is just a predicate invocation with an implicit state variable at
the end. It makes syntax leaner when used properly and I don't see much
reason for not using it for parsers. You can also mix DCG syntax with state
variable syntax.

Cheers, 
Volker

> > 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