Closed okrosa closed 11 years ago
Well, currently this is not very useful. However, I could imagine places where we could use list literals in the (far?) future.
How about an \in / element-of operator? E.g. to iterate over elements in a comma-separated list attribute: Element \in eval(S.split(","))
Now we can also use literal lists here, and even handle them more concisely and efficiently then constants in separate bodies:
pattern red(Deck, Card) = {
find contains(Deck, Card);
Card.suite(Card, Suite);
Suite \in {HEARTS, DIAMONDS};
}
Instead of:
pattern red(Deck, Card) = {
find contains(Deck, Card);
Card.suite(Card, Suite);
Suite == HEARTS;
} or {
find contains(Deck, Card);
Card.suite(Card, Suite);
Suite == DIAMONDS;
}
Or:
pattern red(Deck, Card) = {
find contains(Deck, Card);
Card.suite(Card, Suite);
find diamondsOrHearts(Suite);
}
pattern diamondsOrHearts(Suite) = {
Suite == DIAMONDS;
} or {
Suite == HEARTS;
}
(this latter form would be the closest to how such a literal list would behave with \in )
@bergmanngabor Don't mix issues. In the future, this feature might make sense, but before the release, this feature is more of a bug.
Updated grammar - it seems to disallow the lists in constraints. However, somehow the test framework does not know about this, so I could not create a test case that verifies this functionality.
I would be glad for some manual testing before closing this issue.
Of course, because of a grammar change a grammar regeneration is necessary.
The system accepts list literal values in pattern bodies (even with different values in it):