[alg] problemen met union types.

[Alarmnummer]

Ik ben wat aan het stoeien met een typesysteem en ik heb ruzie gekregen met mijn union types. Als ik bv een class(type) heb, dan kan dit alleen een subtype zijn van een interface of een andere class.

Maar stel dat ik de volgende union type ga maken:
union(class1,class1)

dan is class1 een subtype hiervan, omdat de verzameling van waarden voor class1 een deelverzameling is van die union. (Tenslotte is die union een verzameling van alle waarden voor class1).

Wie kan mij een beetje op het goeie spoor helpen?

[edit]
Ik zit zelf denk ik wel redelijk op het goeie spoor. Je moet kijken of het een subtype is van het linker type, of van het rechtertype van de union. Maar gewoonlijk is het zo dat een class alleen een subtype is van een andere class als hij ervan extend, maar in het geval van union types gaat deze vlieger niet op. *zit beetje met zijn isSubType systeem te klooien*

[ Voor 43% gewijzigd door Alarmnummer op 03-03-2003 23:54 ]

[LordLarry]

Kan je hier een praktisch voorbeeld van geven in 1 of andere taal? Ik vind het moeilijk voor te stellen wat je bedoelt.

[Alarmnummer]

In de meeste talen is het gebruikelijk dat de null waarde een van de mogelijke waardes is van een object. Maar je zou ook kunnen zeggen null geen element mag zijn uit die mogelijke waardes (je maakt een apart Null type aan die maar 1 waarde heeft, namelijk null). Als je wilt dat een variable ook null mag zijn, dan moet je dat aangeven bij zijn declaratie en dat zou je als volgt kunnen doen:

String a; //a kan niet null zijn
?String b; //b kan null zijn

Nu heeft b dus een bepaald type, namelijk een union tussen de types Null en String.

voordeel?

Stel dat ik de volgende functie heb:
?String bar(){...}

en de volgende declaratie+toekenning:
String foo = bar();

Dan gaat dit een compiletime fout opleveren, omdat ?String geen subtype is van String.

[ontopic]
Ik ben het volgende tegengekomen in de artikelen van Luca Cardelli:

a1<:b1 a2<:b2:
-----------------------
union(a1,b1)<:union(a2,b2)

Dit is de enigste subtype regel die ze geven voor uniontypes en hieruit kan ik het bovenstaande dus niet afleiden.

[ Voor 17% gewijzigd door Alarmnummer op 04-03-2003 10:26 ]

[mbravenboer]

Volgens mij heb je ook juist een andere regel nodig. ?String is een union van null en String. Je probeert iets van het type ?String aan String toe te wijzen. Het punt is dat niet alle elementen van het type ?String van het type String zijn.

Heb je het boek "A Theory of Objects" van Abadi en Cardelli? Die kan ik je sterk aanraden als je dol bent op dergelijke stuff .

[Alarmnummer]

mbravenboer schreef op 04 maart 2003 @ 10:20:
Volgens mij heb je ook juist een andere regel nodig. ?String is een union van null en String. Je probeert iets van het type ?String aan String toe te wijzen. Het punt is dat niet alle elementen van het type ?String van het type String zijn.

precies.

Heb je het boek "A Theory of Objects" van Abadi en Cardelli? Die kan ik je sterk aanraden als je dol bent op dergelijke stuff .

Ik heb hier:
Typefull Programming : Luca Cardelli
On understanding of .... : Luca Cardelli
TypeSystems: Luca Cardelli.

Ik kan hierin geen extra informatie vinden over union types. Nouja.. ik zal even kijken in jouw aanrader.


[edit]
Hmmz.. die kan je niet downloaden

[ Voor 5% gewijzigd door Alarmnummer op 04-03-2003 10:26 ]

[mbravenboer]

Nee idd, het is een volledig boek . Maar je bent toch zo dol op boeken? .

Overigens definieert die regel hierboven de subtype relatie op unions als ik het goed zie (kom er een beetje rauw invallen ). Op zich is dat denk ik wel wat je nodig hebt, maar werken met definities is misschien lastig in deze context. Helaas kan ik niet even op zoek gaan naar wat info want ik heb het bewuste boek hier niet bij de hand .

[Verwijderd]

Waarom kijkt je niet af van een taal die het onderscheid in nullness al maakt zoals Nice?
Hmm, ik zie dat je in dat geval ook typeparameters moet ondersteunen.

code:

class Maybe<+T>;//plusje betekent covariant
class Sure<+T> extends Maybe<T>;
class Null<+T> extends Maybe<T>;

[Alarmnummer]

Verwijderd schreef op 04 March 2003 @ 10:38:
Waarom kijkt je niet af van een taal die het onderscheid in nullness al maakt zoals Nice?
Hmm, ik zie dat je in dat geval ook typeparameters moet ondersteunen.

code:

class Maybe<+T>;//plusje betekent covariant
class Sure<+T> extends Maybe<T>;
class Null<+T> extends Maybe<T>;

Nice? Nooit van gehoord (Zie sig). Trouwens dat met die + voor covariant is een goeie oplossing, beter dan dat eeuwige gedonder met:

List<T>{
<T2 extendsT> void addAll(List<T2> l);
}

[ Voor 7% gewijzigd door Alarmnummer op 04-03-2003 10:41 ]

[Alarmnummer]

Ik denk dat ik er al uit ben. Je kan class1 ook schrijven als een union tussen class1 en void (ze bevatten beiden alleen de waardes van Class1) Dus:
Union(Class1,Void).

En als je dan de volgende regel doet:

Class1<:Class1 Void<:Null
--------------------------------------------------
Union(Class1,Void)<:Union(Class1,Null)

Maar het algoritme om een subtype te bepalen gaat er niet eenvoudiger op worden zo.

[MSalters]

Alarmnummer schreef op 03 March 2003 @ 23:42:
Ik ben wat aan het stoeien met een typesysteem en ik heb ruzie gekregen met mijn union types. Als ik bv een class(type) heb, dan kan dit alleen een subtype zijn van een interface of een andere class.

Maar stel dat ik de volgende union type ga maken:
union(class1,class1)

dan is class1 een subtype hiervan, omdat de verzameling van waarden voor class1 een deelverzameling is van die union. (Tenslotte is die union een verzameling van alle waarden voor class1).

Wie kan mij een beetje op het goeie spoor helpen?

[edit]
Ik zit zelf denk ik wel redelijk op het goeie spoor. Je moet kijken of het een subtype is van het linker type, of van het rechtertype van de union. Maar gewoonlijk is het zo dat een class alleen een subtype is van een andere class als hij ervan extend, maar in het geval van union types gaat deze vlieger niet op. *zit beetje met zijn isSubType systeem te klooien*

Is er wel een subtype relatie?
Een union van class1 en class2 in niet overal bruikbaar waar een class1 bruikbaar is (stel dat de waarde van de union buiten het domein van class1 ligt).
Een class1 is niet overal bruikbaar waar een union van class2 bruikbaar is, wat als je er een waarde aan wil assignen uit het domein van class2?

Nou is de laatste beperking afhankelijk van het feit of je taal assignment aan objecten ondersteunt. (C++/Java/etc wel, FP niet ).

[Verwijderd]

Alarmnummer schreef op 04 March 2003 @ 10:41:
Nice? Nooit van gehoord (Zie sig).

offtopic:
Ik moet jou nog bedanken voor dat draadje op javahova, waardoor ik Nice ben uitgaan proberen.
Ik zit er nu mee opgescheept dat ik mededeveloper ben van Nice.

[Alarmnummer]

[offtopic]
Ik werk er niet meer mee. Je kan in Nice een subclass niet met een ander aantal typeparameters laten werken, dan de superclass. Dit vind ik niet acceptabel.

[Alarmnummer]

MSalters schreef op 04 March 2003 @ 10:52:
[...]

Is er wel een subtype relatie?

De definitie van subtype die ik ben tegen gekomen is:

als alle waardes van een type een deelverzameling zijn van een ander type, dan is het 1e type een subtype van het 2e. In het geval van Class1 en Union(Class1,Class1) gaat dit op.

Een union van class1 en class2 in niet overal bruikbaar waar een class1 bruikbaar is (stel dat de waarde van de union buiten het domein van class1 ligt).

Yep de verzameling van waardes van Union(Class1, Class2) is groter dan die van Class1. Maar ik heb geen Class2 in mijn voorbeeld staan

[ Voor 32% gewijzigd door Alarmnummer op 04-03-2003 11:05 ]

[Alarmnummer]

Ik had zelf nog een andere oplossing. Je zou een type ook kunnen zien als een verzameling van waarde verzamelingen.

vb:
Int = {Int}
Class1 ={Class1}
Union(Class1,Class1) = {Class1}
Union(Class1,Null) = {Class1,Null}

subtype kan je nu eenvoudig bepalen.

vb
Class1<:Union(Class1,Class1)
is {Class1} deelverzameling van {Class1,Null}?
en dat is dus zo.

Op deze manier wordt het checken van een subtype geloof ik een stuk makkelijker.

[edit]
Met Subtypes van Classes gaat het ook goed:

vb:

Slager<:Persoon
{Slager} is deelverz. van {Persoon}
aangezien iedere slager een persoon is, gaat dit dus ook op.

[ Voor 25% gewijzigd door Alarmnummer op 04-03-2003 11:32 ]

[Alarmnummer]

Het gaat tot zover eigelijk best goed. Ik heb een dikke unit test (met meer dan 100 test erin) om subtypes te bepalen.


Een kleine selectie

code:

Testcase: Function():Boolean<:Function():Boolean |-true took 0 sec
Testcase: Function():Equable<:Function():Equable |-true took 0 sec
Testcase: Function():Boolean<:Function():Equable |-true took 0 sec
Testcase: Function():Equable<:Function():Boolean |-false took 0 sec
Testcase: Function():Boolean<:Function():Union(Boolean, Null) |-true took 0 sec
Testcase: Function():Union(Boolean, Null)<:Function():Boolean |-false took 0 sec
Testcase: Function():Boolean<:Function(Boolean):Void |-false took 0 sec
Testcase: Function(Boolean):Void<:Function(Boolean):Void |-true took 0 sec
Testcase: Function():Union(Boolean, Null)<:Function():Union(Boolean, Null) |-true took 0 sec
Testcase: Function(Boolean):Void<:Function(Equable):Void |-false took 0 sec
Testcase: Function(Equable):Void<:Function(Boolean):Void |-true took 0 sec

Ik ben nu een beetje aan het klooien met operatoren, methodes en functies. Wat is eigelijk nog het verschil

1+2
+(1,2)
1.+(2)

[ Voor 72% gewijzigd door Alarmnummer op 04-03-2003 16:01 ]