Thomas Linder Puls: release

2019-03-12T16:13:05Z

release

← Older revision		Revision as of 18:13, 12 March 2019
Line 1:		Line 1:
	{{languageReferenceNavbar\|Bounded polymorphism}}		{{languageReferenceNavbar\|Bounded polymorphism}}

	~~{{Template:NonReleased}}~~

	The following example can be used as a motivation for bounded polymorphism.		The following example can be used as a motivation for bounded polymorphism.

Thomas Linder Puls: Not released

2019-02-25T15:33:16Z

Not released

← Older revision		Revision as of 17:33, 25 February 2019
Line 1:		Line 1:
	{{languageReferenceNavbar\|Bounded polymorphism}}		{{languageReferenceNavbar\|Bounded polymorphism}}

			{{Template:NonReleased}}

	The following example can be used as a motivation for bounded polymorphism.		The following example can be used as a motivation for bounded polymorphism.

Thomas Linder Puls: navbar

2019-02-25T15:31:47Z

navbar

← Older revision		Revision as of 17:31, 25 February 2019
Line 1:		Line 1:
			{{languageReferenceNavbar\|Bounded polymorphism}}

	The following example can be used as a motivation for bounded polymorphism.		The following example can be used as a motivation for bounded polymorphism.

Thomas Linder Puls: Thomas Linder Puls moved page Bounded polymorphism to Language Reference/Bounded polymorphism

2019-02-25T15:27:45Z

Thomas Linder Puls moved page Bounded polymorphism to Language Reference/Bounded polymorphism

← Older revision	Revision as of 17:27, 25 February 2019
(No difference)

Thomas Linder Puls: initial

2019-02-25T15:20:53Z

initial

New page

The following example can be used as a motivation for bounded polymorphism.

{{Example|Assume that we have a program with two kinds of persons <vp>client</vp>s and <vp>user</vp>s, and that we have ordered them in a hierarchy like this:
<vip>
interface person
properties
name : string.
...
end interface person

interface client supports person
properties
clientId : unsigned.
...
end interface client

interface user supports person
properties
isAdministrator : boolean.
...
end interface user
</vip>

Using <vp>list::sortBy</vp> we can create predicate that sorts a list of persons by name like this:
<vip>
predicates
sortByName : (person* PersonList) -> person* SortedList.
clauses
sortByName(List) :- list::sortBy({ (L, R) = compare(L:name, R:name) }, List).
</vip>

Due to the (structural subtyping) type rules of Visual Prolog we use this predicate to sort a list of users:
<vip>
SortedList = sortByName(UserList)
</vip>

However, <vp>SortedList</vp> is a list of <vp>person</vp>s rather than a list of <vp>user</vp>s.

So the elements in <vp>SortedList</vp> does not have the <vp>isAdministrator</vp> property.
}}

In this example the elements in the <vp>SortedList</vp> has been "downgraded" from <vp>user</vp> to <vp>person</vp>. But if they are users before we sort them then they are also users after they have been sorted. So we would like to create a sortByName predicate that does not perform such an element downgrade.

So we want to create a predicate that returns the same kind of elements that it receives as input. A polymorphic declaration like this:
<vip>
predicates
sortByName : (Elem* PersonList) -> Elem* SortedList.
</vip>
has the desired property. But it will not work, because this predicate can receive any kind of list as input and you cannot get a <vp>name</vp> from everything.

This is where bounded polymorphism can help. With bounded polymorphism you can state that a a type parameter cannot be anything it has to fulfill some ''bound''.

Bounds have the form <vp>where X supports Y</vp>.

{{Example|In our example we can use bounded polymorphism like this:
<vip>
predicates
sortByName : (Person* PersonList) -> Person* SortedList
where Person supports person.
</vip>
Now the type parameter (i.e. <vp>Person</vp>) can only be a type that supports <vp>person</vp>.

If we call the predicate with a user list (<vp>user*</vp>) then the type variable <vp>Person</vp> will be <vp>user</vp> in the declaration, corresponding to this declaration:

<vip>
predicates
sortByName : (user* PersonList) -> user* SortedList
where user supports person.
</vip>

We can see that:
* The returned list is a <vp>user*</vp>
* The bound is fulfilled because <vp>user</vp> does support <vp>person</vp>.

On the other hand, if we (attempt to) call the predicate with an integer list (<vp>integer*</vp>) the type variable <vp>Person</vp> must have the value integer, corresponding to this declaration:
<vip>
predicates
sortByName : (integer* PersonList) -> integer* SortedList
where integer supports person.
</vip>
Then the bound is not fulfilled because <vp>integer</vp> does '''''not''''' support <vp>person</vp>.
}}

Bounds can be put on polymorphic predicates like above, if you need more than one bound you must write like this:

<vip>
predicates
pred : (<type1> P1, <type2> P2, ...) -> <return>.
where <Sub1> supports <Super1>
where <Sub2> supports <Super2>
....
where <SubJ> supports <SuperJ>.
</vip>

When we have put bounds on the parameters we can exploit them in the clauses.

{{Example|<vp>L</vp> and <vp>R</vp> has types that supports <vp>person</vp>, so we can obtain the <vp>name</vp> property from these variables:
<vip>
predicates
sortByName : (Person* PersonList) -> Person* SortedList
where Person supports person.
clauses
sortByName(List) :- list::sortBy({ (L, R) = compare(L:name, R:name) }, List).
</vip>
}}

Bounds can also be put on classes.

{{Example|Given <vp>person</vp>s from above, we want to create name maps. I.e. we want to map from name to person, but also here we want to be able to use this map for users and customers.

The interface does not reflect that we have <vp>person</vp>s in mind (we could also implement this interface for other things than persons):
<vip>
interface nameMap{@Type}
predicates
insert : (@Type Element).
tryGet : (string Name) -> @Type.
interface nameMap
</vip>
But the <vp>personNameMap</vp> class will only work <vp>person</vp>s
<vip>
class personNameMap{@Person} : nameMap{@Person}
where @Person supports person
end class personNameMap
</vip>
Due to the bound we can use the name property in the implementation of the class:
<vip>
implement personNameMap{@Person}

facts
theMap : mapM{string Name, @Person} := mapM_redBlack::new().

clauses
insert(P) :-
theMap:set(P:name, P). % P has a type that supports person, so we can use the name property

clauses
tryGet(Name) = theMap:tryGet(Name).

end implement personNameMap
</vip>
This class can be used to create a user map:
<vip>
facts
userMap : nameMap{user} := personNameMap::new().
</vip>
And in that map we can insert <vp>user</vp> and we can lookup <vp>user</vp>s (i.e. rather than <vp>person</vp>s) by name.
}}

In bounds the notion of supports is extended to cover non-object types, in the sense that Sub supports Super if Sub is a subtype of Super. As example <vp>integer</vp> is a subtype of <vp>real</vp>.

Language Reference/Bounded polymorphism - Revision history

Thomas Linder Puls: release

Thomas Linder Puls: Not released

Thomas Linder Puls: navbar

Thomas Linder Puls: Thomas Linder Puls moved page Bounded polymorphism to Language Reference/Bounded polymorphism

Thomas Linder Puls: initial