Operator overloading in een dynamisch getypeerde taal*

[.oisyn]

Deze posts zijn afgesplitst uit De Devschuur Coffee Corner - Iteratie ⓬. Ik heb de aftrap van de discussie even meegenomen, maar een betere inleiding staat een paar posts naar beneden

Kent iemand een dynamisch getypeerde taal met operator overloading?

[ Voor 62% gewijzigd door .oisyn op 21-04-2020 01:21 ]

[Ed Vertijsment]

.oisyn schreef op donderdag 16 april 2020 @ 14:27:
Kent iemand een dynamisch getypeerde taal met operator overloading?

Perl misschien?

[Eärendil]

Python

[Ghehe]

ruby http://nicholasjohnson.com/ruby/ruby-course/exercises/operator-overloading/

[.oisyn]

Ik heb operator overloading toegevoegd aan KolQ, maar ik zit met een design dilemma. Operator overloading werkt alleen op objects, niet op andere built-in types zoals numbers of strings. Hoe het nu werkt is dat er wordt gekeken naar de linker operand van een binaire operator. Dus bij een expressie als a+b wordt omgeschreven naar a.opAddition(b). Echter, in het geval dat a een built-in type is en b een object, dan wil ik eigenlijk b.opAddition(a) aanroepen, maar je wil natuurlijk wel weten of het object waar de operator op wordt aangeroepen aan de linkerkant of rechterkant van de operator staat.

Ik kan dat op 2 manieren implementeren: een andere functie aanroepen, bijvoorbeeld opAdditionR, of een extra parameter die aangeeft of this links of rechts stond. Een derde optie is natuurlijk gewoon beide operanden meegeven als parameter, waarbij een van de twee dan ook de this is. Eventueel kan die ook static zijn.

Ed Vertijsment schreef op donderdag 16 april 2020 @ 14:36:
[...]

Perl misschien?

Brrr, niet snel een taal waar ik naar zou kijken als voorbeeld

Eärendil schreef op donderdag 16 april 2020 @ 14:36:
Python

Interessant, Python gaat dus voor de aanpak met een aparte functie voor de R-versie. Bovendien kun je NotImplemented returnen (waardoor hij bij a+b waarbij a wel een implementatie heeft alsnog bij b uit kan komen)

Ghehe schreef op donderdag 16 april 2020 @ 14:36:
ruby http://nicholasjohnson.com/ruby/ruby-course/exercises/operator-overloading/

Ik kan zo snel niet vinden hoe Ruby bovenstaand probleem nou precies oplost... Hier zeggen ze niets meer dan "ja bij 3 + a krijg je een error" in een voetnoot, niet hoe je dat dan oplost .

[Sebazzz]

In C# is operator overloading via een static method altijd. Dan hoef je ook niet te twijfelen over left/right.

[.oisyn]

Sebazzz schreef op donderdag 16 april 2020 @ 15:19:
In C# is operator overloading via een static method altijd. Dan hoef je ook niet te twijfelen over left/right.

C# is statisch getypeerd dus kun je sowieso altijd de juiste implementatie erbij zoeken. Dat kan niet in een dynamisch getypeerde taal.

[Sebazzz]

.oisyn schreef op donderdag 16 april 2020 @ 15:21:
[...]

Dat kan niet in een dynamisch getypeerde taal.

Op punt van uitvoering weet je toch wat de operands zijn?

[.oisyn]

Sebazzz schreef op donderdag 16 april 2020 @ 15:32:
[...]

Op punt van uitvoering weet je toch wat de operands zijn?

Oh ik snap nu wat je bedoelt.

Het punt is niet zozeer twijfel over wat wat is. Alle manieren die ik opnoemde zijn immers eenduidig. Maar in een dynamische taal heb je veel meer last van het feit dat 1 functie alle verschillende types moet afhandelen.

In C# heb je immers nog steeds een verschil tussen een operator+(Foo, Bar) en een operator+(Bar, Foo). Je hoeft niet in je functie types te testen, en bovendien kunnen beide kanten een implementatie toevoegen.

In een dynamische taal weet je hooguit alleen dat Foo en/of Bar een operator+ heeft. Maar je weet niet of Foo ook instances van Bar afhandelt in zijn operator+. Je kunt dan zeggen: de linkerkant bepaalt. Maar dan kom je weer in de knoei met built-in types, want die kun je niet overriden, dus dan bepaalt ineens de rechterkant. In het geval van een static op Foo met twee operands moet je dan ook nog eens gaan opzoeken welke van de twee de Foo is in dit verhaal. Een aparte functie voor als Foo rechts staat is dan wel prettig. Maar wel weer meer implementatiewerk.

[RayNbow]

.oisyn schreef op donderdag 16 april 2020 @ 15:21:
[...]

C# is statisch getypeerd dus kun je sowieso altijd de juiste implementatie erbij zoeken. Dat kan niet in een dynamisch getypeerde taal.

Nadeel van C# is dat je niet kunt abstraheren over operators (bijv. een generieke functie voor alle typen T waarvoor optellen gedefinieerd is).

.oisyn schreef op donderdag 16 april 2020 @ 14:46:
Ik heb operator overloading toegevoegd aan KolQ, maar ik zit met een design dilemma. Operator overloading werkt alleen op objects, niet op andere built-in types zoals numbers of strings.

Wat als je nu operators als functies behandelt die toevallig een symbool als identifier hebben? Vervolgens zorg je dat je taal aan late-binding doet, zoals bijv. VB:

Visual Basic .NET:

Module Program
    Sub Foo(x As String, y As String)
        Console.WriteLine("String,String")
    End Sub

    Sub Foo(x As String, y As Integer)
        Console.WriteLine("String,Int")
    End Sub

    Sub Foo(x As Integer, y As Integer)
        Console.WriteLine("Int,Int")
    End Sub

    Sub Foo(x As Integer, y As String)
        Console.WriteLine("Int,String")
    End Sub


    Sub Main(args As String())
        Dim a As Object = 1
        Dim b As Object = "2"
        Foo(a, b) 'prints: Int,String
    End Sub
End Module

[.oisyn]

RayNbow schreef op donderdag 16 april 2020 @ 16:11:
Wat als je nu operators als functies behandelt die toevallig een symbool als identifier hebben?

Ik zie niet helemaal wat het hebben van symbolen precies toevoegt in deze context

Vervolgens zorg je dat je taal aan late-binding doet, zoals bijv. VB

Late-binding staat wel op mijn wishlist, maar dat wil ik tacklen dmv syntactische suiker en niet in de VM zelf, door een stub te genereren de de nodige tests doet en de offload naar de juiste implementatie.

[.oisyn]

Ik vind Python's oplossing op zich wel aardig, waarbij de left-hand-side (lhs) dus aangeeft dat hij het type niet support waarna de operator wordt geoffload naar de rhs. Dat is dus typisch voor de usecase dat je Foo+Bar wilt supporten terwijl jij Bar maakt en Foo van een derde partij is en die je dus niet aan kunt passen.

Ik weet niet helemaal wat de mogelijkheden zijn in Python verder, maar KolQ is volledig dynamisch en je kunt dus ook gewoon on the fly de operator+ in Foo wrappen als je dat nodig acht. Op die manier voegt Bar dus functionaliteit toe aan Foo. Dat zou ongeveer zo gaan:

code:

Foo.@opAddition = with(old=Foo.@opAddition) => (x) => x is Bar ? AddFooBar(this,x) : old.call(this, x);

[RayNbow]

.oisyn schreef op donderdag 16 april 2020 @ 16:30:
[...]

Ik zie niet helemaal wat het hebben van symbolen precies toevoegt in deze context

Dat was een bruggetje naar het stukje VB-code (in VB kan ik functies alleen alfanumerieke namen geven).

.oisyn schreef op donderdag 16 april 2020 @ 17:32:
Ik vind Python's oplossing op zich wel aardig, waarbij de left-hand-side (lhs) dus aangeeft dat hij het type niet support waarna de operator wordt geoffload naar de rhs. Dat is dus typisch voor de usecase dat je Foo+Bar wilt supporten terwijl jij Bar maakt en Foo van een derde partij is en die je dus niet aan kunt passen.

Op zich is Python wel aardig en dekt het veel gevallen af. Soms kun je, ook al is Foo van een derde partij, het in Python monkeypatchen en alsnog bijv. __add__ toevoegen aan Foo.

Waar Python tekort kan schieten is wanneer zowel Foo en Bar van een 3e partij zijn en niet te monkeypatchen is. In dat geval kun je noch __add__ toevoegen aan Foo, noch __radd__ aan Bar.

[SPee]

.oisyn schreef op donderdag 16 april 2020 @ 14:27:
Kent iemand een dynamisch getypeerde taal met operator overloading?

Groovy?

[RayNbow]

SPee schreef op donderdag 16 april 2020 @ 21:47:
[...]


Groovy?

Doet Groovy meer dan single dispatch op de linker operand?

[Xiphalon]

.oisyn schreef op donderdag 16 april 2020 @ 14:27:
Kent iemand een dynamisch getypeerde taal met operator overloading?

Niet direct. Maar operator overloading is een vorm van polymorphisme, dus bv Smalltalk.

Mijn compiler-nerd-alert zou deze suggesteren.

[.oisyn]

@Xiphalon Bedankt voor de suggestie, maar ik ben wel een beetje bekend met het onderwerp