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

Assert domain from set of values #13

Open
lewtds opened this issue Dec 8, 2020 · 4 comments
Open

Assert domain from set of values #13

lewtds opened this issue Dec 8, 2020 · 4 comments

Comments

@lewtds
Copy link

lewtds commented Dec 8, 2020

I see from your knight's tour example , you wrote a small utility to convert a list of values to a domain:

foldl(num_to_dom, Nexts, Next, Dom)

where:

num_to_dom(N, D0, D0\/N).

I think this should be part of the library itself. Something like:

Var in_set [1, 2, 3, 4]
Vars ins_set [1, 2, 3, 4]
@triska
Copy link
Owner

triska commented Dec 8, 2020

Thank you, this is certainly worth considering!

Do you have any concrete use case in mind? In my experience, this need arises quite rarely.

Maybe it would be even more useful to add a predicate like domain_list/2 or list_domain/2, which can be used in both directions, relating a domain to a list of integers? This would be more versatile, and take only a single additional predicate that can be used in conjunction with both (in)/2 and (ins)/2.

@lewtds
Copy link
Author

lewtds commented Dec 9, 2020

I have not played around enough with Prolog and clpfd/z to have a concrete use case right now but from the top of my head, from dealing with other languages, discrete domains happen all the time, like HTTP status code for example, that's why they usually have the Enum type with custom values.

Agree with the list_domain/domain_list suggestion. I think that's a much more general approach!

@triska
Copy link
Owner

triska commented Dec 9, 2020

OK! Please let's leave this issue open for now, and implement it when there is a clear need for it.

One reason why I do not immediately add it is that every new primitive for reasoning about domains will reduce compatibility with other constraint systems. Another reason is that beginners tend to quickly adopt bad patterns if too many primitives are available. For example, we will quickly see:

list_domain([400,402,404], Dom), X in Dom

which can already now be written more compactly and also more portably as:

X in 400\/402\/404

Would this solve your issue with HTTP status codes?

Also, we will likely even see:

list_domain([1,2,3], Dom), X in Dom

which can be written as:

X in 1..3

I have seen this occur repeatedly in the past. For instance, library(pio) provides phrase_from_file/2, and there are also libraries that provide phrase_from_stream/2. Beginners will quickly find a way to use the most complex and least portable combination of predicates, when a single phrase_from_file/2 would be sufficient.

Therefore, if at all possible, I would like to keep the provided features as simple and as portable as possible. I'm certainly sympathetic to adding list_domain/2, and I will do it once a few good use cases become known. If anyone has them, please provide them.

@lewtds
Copy link
Author

lewtds commented Dec 10, 2020

That's reasonable. At list this issue can serve as a pointer to anyone having the same problem.

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

No branches or pull requests

2 participants