"Sinterklaas issue": Atoms mentioned in an expression should not populate the corresponding concept implicitly

[hanjoosten]

Currently, if you have a singleton in an expression, it will be used to automatically fill the initial population. I think that is wrong.

I have uploaded a tiny example script.

@stefjoosten, Do you share my opinion? If so, it will be relative easy to fix. If not, please explain!

Hi @hanjoosten, Stef here. I agree. Let's abolish the practice to pre-populate concepts with atoms from singleton-expressions. For the reasons why, please read the following comments in this issue.

[sjcjoosten]

I am in favour of this: I believe writing a rule/expression/etc should not influence the initial population. I do not agree that it would be easy to fix. Currently, singletons are used as atoms that cannot (or should not) be deleted. Of course, such an assumption should be made explicit through a rule:

RULE godExists : I[ONE];V;"God"[Deities];V;I[ONE] = I[ONE]
MEANING "There is a Deity we call God"

or alternatively:

DECLARE god :: ONE*Deity [TOT] -- there is at least one god
RULE godExists : I[ONE];god;"God"[Deities] = god
MEANING "God is a god"

I am not sure how well these work if we delete atoms. I fear that the normalizer or the SQL-generator may assume that 'God' always exists. If both of the above examples already work, then I agree that it will be relatively easy to fix, and believe it should be fixed.

We can still express your rule using the current semantics:

CONTEXT SinterklaasTest IN DUTCH
CLASSIFY Persoon IS Persoon /\ Everything
RULE toBeOrNotToBe : V[Persoon*Persoon]-"Sinterklaas"[Everything]
MEANING "'Sinterklaas' bestaat niet als persoon."
ENDCONTEXT

However, I really do not like the fact that a RULE can be used to populate concepts. Adding rule X to a script containing rule Y with has no violations, can cause rule Y to be violated. Or worse: adding an interface to a script might do the same. This is not desirable and the alternative, which is having to make it explicit (with a RULE) when you want an atom to always exist.

[stefjoosten]

I love the example. Children will love it too. Ampersand will help them to stay convinced that Sinterklaas exists! And yes! So there will be presents for evermore!!!!

:-)

[stefjoosten]

Nevertheless, I also like the more fundamental aspect: Sinterklaas demonstrates clearly the contradictions we will suffer by populating scripts implicitly. It seems a convincing plea for requiring the Ampersand user to populate explicitly.
to be continued....

[stefjoosten]

There is a way out, of course.
If we distinguish positive use of singletons (e.g. "Sinterklaas") from complementary use of singletons (e.g. -"Sinterklaas"), we could restrict the implicit singleton definition to positive uses. However, I fear that this is undecidable in the general case (@sjcjoosten: is this the case?).
If undecidable, there still is a way out. We could restrict the implicit singleton definition to provably positive uses. That would make Han's example work. But aren't things getting too complex?

What about the original motivation for having implicit singleton definitions. Is it suddenly useless?

[sjcjoosten]

I do not like the idea of distinguishing between positive and negative occurrences, but let's try to see if we can make it work: if a \/ b occurs positively, then so do a and b, if a;b occurs positively, then so to a and b, if a-b occurs positively, then so does a, and b occurs negatively, etc.
This all seems pretty decidable to me. So let's focus on the tricky cases:
if a |- b occurs as a rule, I argue that both a and b should occur positively (instead of having a occur negatively). The reason is that each term cannot occur both positively and negatively, and that would happen if a = b is equal to a |- b and b |- a.
Of course, we lose some of the mathematical elegance by this: a |- b is no longer equivalent to V = -a \/ b, and for rules with a = -V things become ridiculous: in it, a occurs positively, while V occurs negatively. Also, try writing this rule:
If "Sinterklaas" exists, "Sinterklaas" comes by "Boat"
The right-hand side would normally be written as "Sinterklaas";comesby;"Boat", but now we want "Sinterklaas" to occur negatively. I believe this will become very difficult to write.

Now for your way out.. say we only look at provably positive uses. In most cases, we can have the atom not exist while the rule is not violated, simply by creating an empty concept. The only rules for which this is not the case, are rules in which both types are ONE. So basically, rules that look like this:

RULE godExists : I[ONE];V;"God"[Deity];V;I[ONE] = I[ONE]

Note that the following rule is satisfied if there are no Deities:

RULE godExists : I[ONE];god;"God"[Deity] = god MEANING "God is the only god"

So how does this rule say that God exists? It doesn't. But the TOT constraint says there is at least one Diety, and god (the relation) refers to it.

DECLARE god [ONE*Deity] [TOT] -- there is at least one god

So when writing the first rule, if our engine is smart enough, the atom will be inserted automatically. When writing the second, it would not. I fear this would make it impossible to predict whether I need that separate populate statement.

So I am not in favor of this either.

Another alternative could be: if an atom occurs with a type, e.g. "Sinterklaas"[Persoon], then that means Sinterklaas is a Persoon, if it occurs without one, e.g. "Sinterklaas", then it doesn't. This would be a serious change in Ampersand, as it requires type-less atoms (which might be a good thing). In this view, all atoms exist in the universe of atoms, but some are not within a certain concept. I like this view, but fear that it will have nasty side-effects when trying to write rules without a type for the atom. The main argument against this is that we're still trying to do two things at once.

The least exciting alternative, which I think is a good idea, would be to see some syntax sugar for the rule that an atom exists, and the corresponding POPULATE statement:

EXISTS "Sinterklaas" IN Persoon

... or something like that.

We can experiment with warnings in case "Sinterklaas"[Persoon] occurs in a positive expression without the corresponding exists-statement.

[hanjoosten]

The latter statement already exists, However, the syntax is

POPULATION Persoon CONTAINS [ "Sinterklaas"]

So we already have a way to specify the initial population, without the need to implicitly populate concepts with singletons used in expressions.

[sjcjoosten]

No the latter statement would be equivalent to:

POPULATION Persoon CONTAINS [ "Sinterklaas"]
RULE "Sinterklaas EXISTS" : I[ONE];V;"Sinterklaas"[Persoon];V;I[ONE] = I[ONE]

which, indeed, both exist (this is why it's syntax sugar)

[hanjoosten]

I confronted @stefjoosten with the consequences of the outcome of this discussion this morning. He seems to realize that this is a fundamental issue. A relevant question in this discussion, I remember, is:

What should be the violation mentioned by the rule, when the atom does not exist.

I tried that with the rule above given by @sjcjoosten:

CONTEXT WhatIsTheViolation IN ENGLISH
  RULE "Sinterklaas does not EXIST" : I[ONE];V;(V[Persoon*Persoon] - "Sinterklaas"[Persoon]);V;I[ONE] = I[ONE]
ENDCONTEXT

The outcome is as I expect it to be:

Checking on rule violations...
Violations of rule "Sinterklaas does not EXIST":
 - [(1,1)]

No signals for the initial population.

ERROR: No prototype generated because of rule violations.

Now please bring up the opinion of real Mathematicians...

[stefjoosten]

What about:

RULE -"Sinterklaas"[Persoon]
MEANING "There is no atom Sinterklaas in the concept Persoon"

case 0

If "Sinterklaas"[Persoon] pre-populates concept Persoon, we have an instant contradiction. Any script that contains this rule will never hit the hardware.

case 1

If concept Persoon is not pre-populated, we have an atom without a type. The consequence is that the meta-relation pop in Atoms.adl need not be total. This implies that Ampersand supports type-less atoms. This contradicts a belief that I built up from the Braga-experiments.

Experiment

Thank you, @hanjoosten, for doing an experiment with this. The current implementation produces the following violation:

• [("Sinterklaas","Sinterklaas")]

Because of this, the compiler generates no prototype. Explaination: the compiler "pre-populates" the concept Persoon with atom "Sinterklaas". That produces a violation, because the rule says that "Sinterklaas" should not be in the population of Persoon.

What does this tell me?

This example and the experiment seem to corroborate the opinion of @sjcjoosten (see above) when he says that we should not pre-populate concepts with atoms taken from singleton-expressions.

[stefjoosten]

Let's close this issue when the compiler has been corrected.

[hanjoosten]

The fix was premature, but has been fixed correctly on 20 mar.

[RieksJ]

Given that this issue has been referenced by quite a few others, indicating that users don't naturally think of the stuff in this issue, would it be useful, to extend the POPULATION syntax such that you can make a particular set of atoms (or pairs) persist in that population, e.g., as follows:

POPULATION Deities PERSISTENTLY CONTAINS [ "God" ] 
RULE ThereIsNoOtherGodThanGod : I[Deities] = "God"[Deities]

[hanjoosten]

Introducing new syntax isn't to be taken too lightly. New syntax adds complexity to the language. Modelers have to learn and understand the new construct, which can increase the cognitive load and make Ampersand harder to master. Over time, this could lead to a bloated language, where there are multiple ways to achieve the same result, causing confusion.

In this case there is no need, for you can use the following:

POPULATION Deities CONTAINS [ "God" ]
RULE ThereIsNoOtherGodThanGod : I[ONE] = V[ONE*Deities];'God';V[Deities*ONE]