Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove DCGs that have thrown an exception during term expansion #2681

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hurufu
Copy link
Contributor

@hurufu hurufu commented Dec 5, 2024

Some DCG constructs aren't supported and can't be expanded, here we remove offending DCG rule and don't compile it at all – in a similar fashion to what we do when incorrect goal was found – whole predicate isn't getting compiled.

Fixes #2675

I know that request has low priority, but it is so much simpler than loder.pl refactoring, so I just couldn't help myself and fixed it right away.

@triska
Copy link
Contributor

triska commented Dec 5, 2024

Thank you a lot for taking a look at this issue!

Regarding the approach: In which module is null/0 being defined? And further, supposing a definition for null/0 is already present for unrelated reasons in a module that loads library(dcgs), is that then inadvertently removed?

src/lib/dcgs.pl Outdated
@@ -216,7 +219,7 @@

user:term_expansion(Term0, Term) :-
nonvar(Term0),
dcg_rule(Term0, Term).
catch(dcg_rule(Term0, Term), E, (Term = null, format(" ~q~n", [E]))).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A blind catchall just leads to further problems. So restrict it to those terms that make sense here. Further, note that many implementations permit lists of clauses including [].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would also like to use an empty list, but currently Scryer just compiles a clause []/0, which isn't what I want to achieve here. Maybe that is a more deep problem to be solved instead.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One can always define the fact [] with the rule [] :- true.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... and, it is still a catchall.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh... I forgot to push a commit

@hurufu
Copy link
Contributor Author

hurufu commented Dec 5, 2024

Thank you a lot for taking a look at this issue!

Regarding the approach: In which module is null/0 being defined? And further, supposing a definition for null/0 is already present for unrelated reasons in a module that loads library(dcgs), is that then inadvertently removed?

null/0 is defined in dcgs module, so I don't see how realistically will someone define dcgs:null. in their code base, but this is a valid point. Which is connected to a discussion about how to correctly produce no clauses during term expansion...

@hurufu
Copy link
Contributor Author

hurufu commented Dec 5, 2024

Additionally I do think that this has to be fixed in Prolog, because Rust code that generates this warning is applied universally to every compiled clause, so I will need to add an ugly special treatment for -->/2.

@hurufu hurufu marked this pull request as draft December 6, 2024 08:16
Some DCG constructs aren't supported and can't be expanded, here we
remove offending DCG rule and don't compile it at all – in a similar
fashion to what we do when incorrect goal was found – whole predicate
isn't getting compiled.

Fixes mthom#2675
@hurufu hurufu force-pushed the remove-dcgs-that-have-failed-to-expand branch from 6706d38 to ab91121 Compare December 15, 2024 10:42
@hurufu hurufu marked this pull request as ready for review December 15, 2024 10:43
@hurufu
Copy link
Contributor Author

hurufu commented Dec 15, 2024

I think this small PR is ready for review.

  • I didn't use explicit exception, because it will be always rethrown, so I don't think that there is a risk of hiding it.
  • Bad --> is expanded to a long name, so I don't expect any accidental name conflict (also it will be visible only in dcgs module).
  • I decided to rethrow, because I want to rely on a default mechanism of exception printing during goal expansion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DCG compilation: Unexpected warning when using unsupported grammar control construct
3 participants