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

Am Samstag, dem 28.10.2023 um 14:24 +0200 schrieb Volker Wysk:
> 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.

Hmmm... It could be made more concise by using DCG syntax. The implicit DCG
state doesn't need to be a character list...

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

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