Table Of Links Baloldali asztal ABSTRACT absztrakt 1 INTRODUCTION 1 Bevezetés 2 DEPENDENTLY-TYPED OBJECT-ORIENTED PROGRAMMING 2 Függő típusú objektumorientált programozás 3 CASE STUDY 3 Esettanulmány 4 DESIGN CONSTRAINTS AND SOLUTIONS 4 Tervezési korlátok és megoldások 5 FORMALIZATION 5 Formalizáció 6 DE/REFUNCTIONALIZATION 6 DE/refunkcionalizáció 7 FUTURE WORK 7 Jövőbeli munkák 8 RELATED WORK 8 Kapcsolódó munkák 9   CONCLUSION AND REFERENCES 9 Következtetés és referenciák Függő típusú objektumorientált programozás A tipikus objektumorientált és funkcionális nyelven írt programok sok különbséggel rendelkeznek.Most megnézzük, hogyan jelennek meg ezek a különbségek, amikor az objektumorientált stílusban írt programokat figyelembe vesszük. 2.1 Method Call Syntax and Self Parameters Objektum-orientált programozók ismerik a módszer hívás szintaxis o.f(e), hogy hivatkozzon egy módszer f figyelembe argumentum e egy objektum o. Ez néha a neve alatt „egységes funkció hívás szintaxis” mint egy alternatív jelölés a hívás f(o, e), ahol az első argumentum a módszer f az úgynevezett önparaméter. Ebben a bizonyítékban a boolokat adattípusként határozzák meg, a negációt a booloktól a boolokig nem függő funkcióként határozzák meg, és a neg_- fordított funkciót a bool x függő funkciójaként határozzuk meg annak bizonyítására, hogy az x egyenlő a neg(neg x). Rendszerünkben mind a neg, mind a neg_invert funkciókat a nem függő vagy függő funkciók használata nélkül akarjuk kifejezni. def Bool.neg: Bool { Igaz => Hamis, Hamis => Igaz } Ha a függő funkciót neg_inverse-ként szeretnénk hasonló módon kifejezni a booliai megfigyeléseként, akkor hozzá kell adnunk egy funkciót, önparamétereket. Megköthetjük a megfigyelt kifejezést egy változónak, amelyet itt önnek nevezünk, és ezt a változót a megfigyelés visszatérési típusában használhatjuk: def (self: Bool.neg_inverse: Eq(Bool, self, self.neg) { True => Refl(Bool, True), False => Refl(Bool, False) } Ezeknek a módszereknek az önparaméterekkel történő újrafunkcionalizálása diktálja a függő codata típusok első jellemzőjét: önparamétereket a pusztítókban. Bővebben: Bővebben: Bővebben: Bővebben: Bővebben: Bővebben: Bővebben: Bővebben: A codata-nyilatkozatokban az önparaméterek adják a kifejező erőt ahhoz, hogy megfelelően képviseljük az ellenőrzött interfészeket és osztályokat objektumorientált stílusban. 2.2 Verified Interfaces and Classes Az adatstruktúrák és algoritmusok függő nyelveken történő ellenőrzésekor két általános megközelítés közül választhatunk: az intrinsic és extrinsic ellenőrzés.Az intrinsic ellenőrzés segítségével az adatstruktúrát vagy algoritmust a helyesség bizonyítékával együtt határozzuk meg.Az adatstruktúrák intrinsic ellenőrzéséhez általában a típusindexek használatával fejezzük ki a tulajdonságokat, például egy hosszúság-indexelt listában található elemek számát. Hasonló megközelítést alkalmazhatunk objektumorientált stílusban indexelt codata típusok használatával [Thibodeau et al. 2016]. Típusindexek használatával biztosíthatjuk, hogy a megfigyeléseket csak a megfelelő állapotban lévő objektumokra hívják. Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap » Kezdőlap Látjuk, hogy a függő (co)pattern-megfelelésnél szokás szerint megvalósíthatatlan mintamegfelelések merülhetnek fel, amelyeket abszurdként kell megjelölni.Vagyis amikor az üres puffer pufferfelületét végrehajtjuk, nem kell végrehajtanunk az olvasási módszert, mivel soha nem hívható. Azt is szeretnénk támogatni az extrinsic megközelítést, ahol szeretnénk elválasztani objektumainkat a specifikációktól. Jacobs [1995] ad nekünk egy kezdeti koncepciót, hogyan kell elérni ezt a célt. Ő javasol egy rendszer koalgebrai specifikációk, amelyek segítségével ellenőrizni objektum-orientált osztályok. Például a 5a ábra mutat egy koalgebrai specifikáció egy egyelemes puffer, amely mutatja a tartós olvasási (PR) viselkedés: Miután egy elem tárolva, nem lehet cserélni a bolt módszerrel. Ehelyett üresnek kell neveznünk a módszert, hogy kifejezetten kiürítsük a pufferet. Az üres pufferből való olvasás hibát ad vissza. A puffer ezen specifikációja a puffer állapotára utaló állítások soraként kerül megadásra. Rendszerünkben ezt a koncepciót a pusztítók önparamétereivel tudjuk megvalósítani, lehetővé téve számunkra, hogy a specifikációkat a codata típusokra vonatkozó megfigyelésekként fejezzük ki. Az 5. ábrán szereplő codata típus határozza meg a rendszeren belüli állandó olvasási pufferek ellenőrzött felületét. Hasonlóképpen, ezt a megközelítést alkalmazhatjuk a kifejezett interfészekre, például a funktorokra vagy a monádákra. 2.3 Dependent Functions Ellentétben a legtöbb más függő típusú elméletekkel, a függő funkciók Π-típusa nem része az alapelméletünknek, de egy könyvtárban is meghatározható. --̧ Non-dependent Functions codata Fun(a b: Type) { Fun(a, b.ap(a b: Type, x: a): b } -- Dependent Functions codata Π(a: Type, p: a -> Type) { Π(a, p.dap(a: Type, p: a -> Type, x: a): p.ap(a, Type, x) } Javasoljuk, hogy mind a függő, mind a nem függő funkciókat a felhasználó határozza meg a beépített helyett.A Java tervezői úgy döntöttek, hogy ezt a megközelítést követik, amikor a funkcionális interfészek példájaként bevezették a lambda absztrakciókat (Goetz et al. 2014; Setzer 2003) a Java 8-ban. Amellett, hogy csökkentik az alapnyelv összetettségét, egyszerűsítik a helyzetet, ha egynél több funkciótípusunk van. Ez a helyzet a szubstruktúrális rendszerekben, ahol lineáris és nem lineáris funkciók vannak. Például a Rust programozási nyelven három különböző beépített funkciójellemző van Fn, FnOnce és FnMut, amelyek különböznek a vevő modalitásában3 . 2.4 Weak and Strong Dependent Pairs Az előző szakaszban megmutattuk, hogyan határozzuk meg a π-típust. A π-típus esetében nem volt más választásunk, mint hogy codata típusnak4 határozzuk meg, de a Σ-típus esetében választhatjuk, hogy adattípusként vagy codata típusként modellezzük. Ez a választás megkülönbözteti a gyenge és erős Σ-típusokat [Howard 1980]: Az erős Σ-típusokat két vetítéssel rendelkező codata típusként határozzuk meg, ahol a második vetítés megemlíti az első vetítés eredményét a visszatérési típusában; a gyenge Σ-típusokat ellentétben az első és a második elemet párosító egy konstruktortípusként határozzuk meg. Ezeket a két reprezentációt a defunkcionalizáció és a refunkcionalizáció útján lehet egymástól megszerezni. Ez még mindig így van, amikor a nem függő párokat az Σ-típusra általánosítjuk. A 2.3. szakaszban szereplő π-típushoz hasonlóan a Σ-típus egy T-típusú család által indexálva van. Adattípusként azt egy konstruktőrpár határozza meg, amely a T-típusú családot , az A-típusú x elemet és a tanú w-t argumentumként használja. Kodátaként még mindig két π1 és π2 vetítésünk van, mint a nem függő párok esetében. De a második vetítés most az önparamétert használja annak biztosítására, hogy az önπ .1-re alkalmazott T-típusú elemet vissza Valójában az Agda már mindkét módon képviselheti az Σ-típusokat. De van egy figyelmeztetés: Az Agda eredetileg nem volt tervezve codata típusokkal szem előtt tartva, és a codata típusai a függő rekordok felett valósulnak meg, ami korlátozza, hogy milyen típusú codata típusok lehetségesek. Például a destruktőrök sorrendje egy codata típusban Agda számára fontos, így nem tudjuk átrendelni az első és a második vetítést. De miért kell aggódnunk a Σ-típus ezen két alternatív kódolása miatt? Vegyük például Eisenberg et al. [2021], akik megvitatják az egzisztenciális típusok hozzáadását a Haskellhez. Mivel a Haskell mind lusta, mind támogatja a típus törlését, Eisenberg et al. egy olyan kialakításra irányul, amely erős egzisztenciális típusokat használ. Úgy gondoljuk, hogy az adatok és a codata típusok keretét használva még világosabbá tehetjük ezeket a különbségeket. 2.5 Codata Encodings of Natural Numbers A lambda számítás kezdetétől kezdve a kutatók olyan adattípusok funkcionális kódolása iránt érdeklődtek, mint a booli, a természetes számok és a listák. A funkcionális kódolások klasszikus példái az adattípusok egyházi, Scott és Parigot kódolása (lásd Geuvers [2014]; Koopman et al. [2014]). A funkciók a mi szempontunkból csak egy adott példány a codata típus, így érdekel a funkcionális kódolások helyett a codata kódolások általánosabb problémája. Az, hogy az egyházi kódolást egy program Peano számokkal és egy iter funkcióval történő újrafunkcionalizálásából lehet szerezni, már megfigyelték Ostermann és Jabs [2018]; ezt a példát a 6. ábrán újrafogalmazzuk. Megfigyelhetjük, hogy a 6b ábrán található codata típus, amely a természetes számok egyházi kódolását képviseli, nem visszafordítható. Ez megfelel a jól ismert elméletnek, miszerint az egyházi kódolások a tiszta F rendszerben írhatók be. Ha ugyanazt a módszert alkalmazzuk a természetes számok Scott vagy Parigot kódolásának megszerzésére, akkor megfigyelhetjük, hogy a kapott codata típus visszafordítható. Ez megfelel a másik jól ismert elméletnek, hogy ezek a kódolások nem írhatók be a tiszta F rendszerben, és visszafordítható típusokat igényelnek. Még egy lépéssel tovább is mehetünk. Geuvers [2001] kimutatta, hogy ezek az előző kódolások nem tudják kifejezni az indukciót vagy a függő eltávolítást. Az egyik módja annak, hogy megkapjuk a tipizált funkcionális kódolást, amely képes kifejezni az indukciót, az, hogy öntípusokat adjunk hozzá a rendszerhez; ezt a fajta kódolást Fu és Stump [2014] vezette be. Bár nehéz bizonyítani a pontos megfelelést, úgy gondoljuk, hogy a Fu és Stump kódolásának lényeges elképzelése kifejezhető a rendszerünkben a 7. és 8. ábrán. A 7. ábrán az indukciót egy StepFun-típusú segéd codata segítségével kódoltuk, amely egy adott predikat P indukciós lépését kódolja természetes számokon. Az indukciót ezután egy természetes számon az ind ind megfigyelésével fejezik ki, amely az indukció bázis esetét és indukciós lépését érvekként várja. Úgy gondoljuk, hogy ez további bizonyíték arra, hogy a rendszerbe bevezetett önparaméterek természetesen előfordulnak, amikor a nem-függőről a függőbe lépünk. 
 
 
 A szerzők: 
 
 
 
 
 Dávid Binder Ingo Csoport Tim Süberkrüb Klaus Ostermann Authors: 
 
 
 
 
 Dávid Binder Ingo Csoport Átlagos problémák Klaus Ostermann 
 
 A dokumentum a CC 4.0 licenc alatt érhető el. A dokumentum a CC 4.0 licenc alatt érhető el. XIV

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

Why was the 'Hello' afraid to meet 'World'? Because every time they got concatenated, they lost their space!

Concatenation

Ez a hanganyag a történet eredeti nyelvén készült!

Az OOP átgondolása függő típusokon és kódokon keresztül

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

THE LAST DAY OF NEW YORK

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

Of The First and Last Things: Part 1

Of The First and Last Things: Part 3

THE LAST DAY OF NEW YORK

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

Of The First and Last Things: Part 1

Of The First and Last Things: Part 3

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps