Consider the attached toy problem. At time 0, it has 2 facts, 2 goals, and 2 rejectable tokens. The solver merges all 6 tokens together.

My understanding is that facts aren't supposed to be merged (since there are two facts in this initial state at the same time (and it's a timeline), the solver should fail).

Looking at the goal, the 'isFact' information is propagated all over the place. I may have missed something, but it appears nothing is ever done with that information.

Possible code change, that I thought Javier should confirm before it gets put in. In Token::commonInit, do the same thing we do regarding rejectable:

{{ if (fact) stateBaseDomain.remove(MERGED); }}

hmm, it looks like I didn't complete the implementation of facts as I intended.

the proposed fix is a good quick approximation, but probably not what we want in the end. my gut reaction is that facts should be mergeable with other facts, I'll have to sit down and remember what I intended to do here in detail. I'll make an effort to deal with this within the next few days.

Is there a good use case for wanting them to merge with other facts? It's a lot simpler to understand if the difference between fact and goal is simply whether or not 'MERGED' is in the base domain, so I'd lean towards doing that.

Also, I can imagine wanting to use facts to declare a bunch of tokens that I want to keep distinct. This would only work if they won't be merged with each other.

another issue with facts is temporal scope : does it make sense to state facts in the future? in the real world facts should probably be stated in the present or the past only. what about events that will happen with high certainty?, like a medical procedure that has been scheduled for a worker. Or the occurrence of an eclipse, or tide cycles, any events that can be predicted with high certainty by applying the laws of physics?

EUROPA doesn't have a concept of the present anyway, so temporal scope for facts will probably have to be left as a modeling decision, but it's a point that should be made explicit.

regarding comment 3 : I think the intuitive semantics for facts/goals is to be mergeable.

for instance, if you say "fact(lightOn from t=0 to t=10)" and "fact(lightOn from t=3 to t=5)" you'll get cleaner plans and more efficient search if you allow them to merge into a single fact: "lightOn from t=0 to t=10".

as with goals, the user can always explicitly remove the option of merging if that's the behavior desired, however, it's much harder for me to see why people would want to do that for facts, any examples?

I can imagine it for non-timeline classes. For example, supose you have a School with scheduled 'class' predicates. You could set up the initial schedule as a bunch of facts, and wouldn't want them to merge, even if they overlap.

What's a use case for wanting facts to merge with other facts, but not with goals?

Something to consider is whether we even need facts. Obviously nobody has needed it up until now, and as you describe, there are other ways to reduce the state domains.

regarding comment 6: ok, the class schedule is a good example where you may want to avoid merging for facts, my original comment still applies, where it would be better to have the user explicitly remove the option to merge if that's the behavior they want, but active/merge are still open in general.

the case for having goals merge with facts but not the other way around is the main reason in my mind to have a separate fact keyword: a fact is something that is already given and doesn't need support, so it makes sense for a goal to be supported by a fact (if my goal is to turn on the light but it's in fact already on then I don't need to do anything), but not the other way around, having a "fact" disappear into a goal would be semantically confusing and so it would get in the way of using the information that something is fact in inference or search.

the reason why users could do without a "fact" keyword is similar to why they could do without "action/condition/effect", you can express the problems in terms of variables/tokens/objects but you get cleaner modeling if you have those other concepts (granted they shouldn't be obviously redundant), and more importantly, building more intelligent behavior is pretty hard without them. For instance, having action/condition/effect we can write more efficient planners, having facts vs goals should allow us to deal better with real-word/execution updates. We could translate everything to a CSP, use just variables and do away with objects and tokens, but that would make things much more difficult. In my mind fact vs. goal is useful less dramatically, but in the same spirit.

I've looked into fixing this a couple of times in the past but it'll take more than a few minutes, all that needs to be implemented is to ensure that facts can only be merged with other facts and I think we'll have a consistent implementation.

I've added a checkError in 6753 to make sure that facts are only merged onto other facts. How the user should be made aware of having tried something silly isn't well thought-out in Europa yet.