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

[Sean Charles (emacstheviking)]

> On 28 Oct 2023, at 13:28, Volker Wysk <post at volker-wysk.de> wrote:
> 
> 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 was, in my original post, it was using only DCG syntax!!!

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

I have indeed used accumulators with DCG rules, it's just that the DCG form manages the final one for me if you like, and yes I know it doesn't have to be a character list, in this case it is a list of tokens from the lexer.  In other places I sometimes have used the =(X) and :=(X) to manage a state object, but I found it to be cumbersome at times so I stopped doing that particular thing.

I've also been contemplating making a command line tool out of the term-rewriting example code but something tells me not to do that yet... maybe when version one is completed I can then consider that it might be possible to clean up the code by introducing a build step however, I really do prefer looking at the code and knowing that that's it, there is no other thing to consider at that point.

Mercury can sometimes be hard to 'reduce' down, with other languages like Haskell, I find it very very easy to reduce things down to composable functions but as of yet, that level of skill has yet to be mine;  I did manage to write a simple parser combinator experimental thing but I had issues with the visual clarity of the code and moved on. The code also moved on, I've yet to find it again on my machine or bitbucket. I *know* I didn't imagine it.

My main issue was finding operators that aren't already taken, in Prolog you can pretty much define what you want within the rules eg "===>", but in Mercury you have to find something not used by any modules you've imported, I found that '//' and '**' seemed to work most of the time, or of course you can use 'foo' names in apostrophes but it just doesn't work that well for my eyes.

The best example I've found to date is in the config.m file of the 'mmc-doc' project by Julian Fondren from 2019.




>> Cheers, 
>> Volker
>> 
>>>> On 28 Oct 2023, at 12:05, Zoltan Somogyi <zoltan.somogyi at runbox.com>
>>>> wrote:
>>>> 
>>>> 
>>>> On 2023-10-28 21:53 +11:00 AEDT, "Volker Wysk" <post at volker-wysk.de>
>>>> 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
>> users at lists.mercurylang.org <mailto:users at lists.mercurylang.org>
>> https://lists.mercurylang.org/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20231028/44406df9/attachment-0001.html>