With non-unique definitions we can use partial definitions.

binding rules

	EntityTypeDef(ent-or-rel, e-ty, _) :
		defines non-unique EntityType e-ty
			of entity-or-relation ent-or-rel
		scopes Attribute
		scopes Role
		scopes This
		implicitly defines This This()
			of type e-ty

	Role(EntityType(role-ty), role-mu, role, inverseName) :
		defines Role role
			of type role-ty
			of multiplicity role-mu
		defines non-unique EntityType role-ty
		  scopes Inverse
		defines Inverse inverseName
			of multiplicity role-mu
			of type e-ty
			where This() resolves to This this
			and this has type e-ty

example program:
(both entity Person and Person 1 Husband <- x partially define Person)

entity Person{}
relation Marriage{
	Person 1 Husband <- x
}

Result in duplicate entries

def / Module:"debug"#0 / EntityType:"Person" /
def / Module:"debug"#0 / EntityType:"Person" /

Which results in duplicate types

prop / Module:"debug"#0 / EntityType:"Marriage" / Role:"Husband"#0 / -- Type() >>
[
    "Person"{use def / EntityType:"Person" / Module:"debug"#0 /, def / EntityType:"Person" / Module:"debug"#0 /},
    "Person"{use def / EntityType:"Person" / Module:"debug"#0 /, def / EntityType:"Person" / Module:"debug"#0 /}
]

Since this are partial definitions of the same thing there should be just a single type here.

Maybe partial (non-unique) definitions should define just a single index entry instead of multiple. (although maybe there are semantic or technical reasons why this not a good idea.)

If there should be multiple definitions and multiple types (which are duplicated with each indirection, a thing having a duplicate type which is declared duplicate will get 4 results, etc) then what task do I use to get uniques?

Submitted by Daco Harkes on 20 June 2014 at 00:06

Guido: definition of should remove duplicates, that should solve it.

I’m currently refactoring the index, one thing that will change is that it will now allow duplicate key/value pairs any more. The uniqueness of the value depends on the term and its origin position, so two terms with different origin positions can still be stored. Maybe that will solve this problem? As for the task, there is no task that does this at the moment, but you could write one. See the other task definitions in tasks/tasks.str in the runtime libraries.

Resolving non-unique names yields all the definitions of a non-unique name. This is intended behaviour. But when storing a property with a resolution to a non-unique name, this yields to the same property several times. I assume this is related to wrapping stored properties in an ID task.

@Gabriël: There is a MakeSet task already. Maybe wrapping properties with this task instead of an ID task would fix it?

Pull request that fixes this: https://github.com/metaborg/runtime-libraries/pull/13

Pull request with fix has been merged.