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.

Sign up for GitHub

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

Jump to bottom

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
Open

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

wants to merge 1 commit into from
+19 −2

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?

UWN
UWN reviewed Dec 5, 2024
View reviewed changes
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
@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 •
edited
Loading

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. (@UWN if you think that it is still a good idea to have explicit exception term, I can put it)
  • Bad --> is expanded to a long name, so I don't expect any accidental name conflict.
  • I decided to rethrow, because I want to rely on a default mechanism of exception printing during goal expansion.

@mthom
Copy link
Owner

mthom commented Dec 21, 2024

looks good to me. further comments?

@hurufu
Remove DCGs that have thrown an exception during term expansion
a599a11 
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 ab91121 to a599a11 Compare December 22, 2024 09:38
@hurufu
Copy link
Contributor Author

hurufu commented Dec 22, 2024

  1. I've just removed some leftover code from unit test.
  2. I think style check should only verify files that have been touched by the commit, because now it fails for files that I haven't modify.

@triska
Copy link
Contributor

triska commented Dec 22, 2024

This just became infinitely more elegant!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@UWN UWN UWN left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

DCG compilation: Unexpected warning when using unsupported grammar control construct
4 participants
@hurufu @triska @mthom @UWN