XSB support for predicates with same name but different signature

[Joachim Jansen]

For example, support for the following vocabulary:

vocabulary V {
  type T
  T(T)
  T(T,T)
}

[Joachim Jansen]

Removed detection of duplicate generation of facts

This would never happen but would filter out fact generation because the _loaded list does not take arity into account.

E.g.: with a type T and predicate T(arg,arg...) both given. The predicate would not be generated

Even when using name() instead of nameNoArity() this leads to problems

E.g. when a predicate T(arg) and function T(arg):arg are given. One of the two would not be generated.

The filter of open symbols that would be already "loaded" is useless to begin with: they are always only generated once. The _loaded list is only useful for detecting which sorts are already generated as ranges (in the getRanges() method).

This fixes issue #440.

→ <<cset cc7002f3619a>>

[Broes De Cat]

I don't understand the explanation. Does it work now? Will it work for a vocabulary with T(T1) T(T2) in it?

[Joachim Jansen]

It will not work for the example you give, since their XSB signature (T/1) is the same. I am filing a new bug report for your case.

[Broes De Cat]

Why not just solve it by using the full quantified names (namespaces + symbolname + typenames)?

[Broes De Cat]

Opened due to previous comments

[Joachim Jansen]

Removed detection of duplicate generation of facts

This would never happen but would filter out fact generation because the _loaded list does not take arity into account.

E.g.: with a type T and predicate T(arg,arg...) both given. The predicate would not be generated

Even when using name() instead of nameNoArity() this leads to problems

E.g. when a predicate T(arg) and function T(arg):arg are given. One of the two would not be generated.

The filter of open symbols that would be already "loaded" is useless to begin with: they are always only generated once. The _loaded list is only useful for detecting which sorts are already generated as ranges (in the getRanges() method).

This fixes issue #440.

→ <<cset cb22c3114301>>

[Joachim Jansen]

Bugfix for predicates with same name + arity but different sorts

For this a fqn_name() procedure is needed in PFSymbol.

This fixes bug #440 completely

→ <<cset 3414ccc29192>>

[Joachim Jansen]

Bugfix for predicates with same name + arity but different sorts

For this a fqn_name() procedure is needed in PFSymbol.

This fixes bug #440 completely

Also added a test for this

→ <<cset a639ef886df4>>

[Joachim Jansen]

Removed detection of duplicate generation of facts

This would never happen but would filter out fact generation because the _loaded list does not take arity into account.

E.g.: with a type T and predicate T(arg,arg...) both given. The predicate would not be generated

Even when using name() instead of nameNoArity() this leads to problems

E.g. when a predicate T(arg) and function T(arg):arg are given. One of the two would not be generated.

The filter of open symbols that would be already "loaded" is useless to begin with: they are always only generated once. The _loaded list is only useful for detecting which sorts are already generated as ranges (in the getRanges() method).

This fixes issue #440.

→ <<cset 483b895767dc>>

[Joachim Jansen]

Bugfix for predicates with same name + arity but different sorts

For this a fqn_name() procedure is needed in PFSymbol.

This fixes bug #440 completely

Also added a test for this

→ <<cset c542203c969c>>

[Joachim Jansen]

Removed detection of duplicate generation of facts

This would never happen but would filter out fact generation because the _loaded list does not take arity into account.

E.g.: with a type T and predicate T(arg,arg...) both given. The predicate would not be generated

Even when using name() instead of nameNoArity() this leads to problems

E.g. when a predicate T(arg) and function T(arg):arg are given. One of the two would not be generated.

The filter of open symbols that would be already "loaded" is useless to begin with: they are always only generated once. The _loaded list is only useful for detecting which sorts are already generated as ranges (in the getRanges() method).

This fixes issue #440.

→ <<cset 39422e4ad2e6>>

[Joachim Jansen]

Bugfix for predicates with same name + arity but different sorts

For this a fqn_name() procedure is needed in PFSymbol.

This fixes bug #440 completely

Also added a test for this

→ <<cset f2ffafb44bcd>>