Funarg probléma

Funarg  - a "funkcionális argumentum" rövidítése; a számítástechnikában a funargue probléma a funkciók első osztályú objektumként való megvalósításának nehézségére utal verem-orientált programozási nyelvekben (a legtágabb értelemben, beleértve az összes olyan nyelvet, amelyen a paraméterek a veremen keresztül kerülnek átadásra a függvényeknek).

Bonyolultság akkor következik be, ha a függvénytörzs közvetlenül (például nem paraméterátadáson keresztül) hivatkozik azokra az azonosítókra, amelyek abban a környezetben vannak definiálva, amelyben a függvény definiálva van, és nem a hívás környezetében [1] . Összegezve a következő okfejtést, a két standard megoldás az ilyen hivatkozások tiltása, vagy lezárások létrehozása [2] .

A problémának két változata van: a növekvő funarg probléma akkor jelentkezik, amikor egy függvény visszatér valamelyik függvényből, a csökkenő funarg probléma akkor merül fel, ha egy függvényt  paraméterként adunk át valamilyen függvénynek.

The Rising Funarg Problem

Amikor egy függvény a normál programvégrehajtás során meghív egy másikat, a hívó függvény helyi állapotát (beleértve a paramétereket és a helyi változókat) el kell menteni, hogy a meghívott függvény visszatérése után a végrehajtás folytatódhasson. A legtöbb lefordított programban ez a helyi állapot a hívási veremben van tárolva egy veremkeretnek nevezett adatstruktúrában . Ez a veremkeret a belső függvény meghívásakor a hívásverembe kerül, és onnan eltávolítva, amikor visszatér. A bugyborékoló funarg probléma akkor fordul elő, amikor a hívó a hívott fél állapotára hivatkozik, miután a hívott fél visszatért. Ezért a hívott függvény állapotát tartalmazó veremkeretet nem szabad felszabadítani, amikor visszatér, megtörve a veremorientált függvényhívási paradigmát.

A bugyborékoló funargs probléma megoldása az, hogy a veremkeretet a kupacra helyezik a hívásverem helyett, valamilyen szemétgyűjtésre támaszkodva, hogy biztosítsák , hogy a veremkeretek által elfoglalt erőforrások felszabaduljanak, amikor már nincs rájuk szükség. A halmon lefoglalt veremkeretekkel való munka sokkal kevésbé hatékony, mint a veremben, így ez a stratégia jelentősen csökkentheti a teljesítményt.

Ha a befoglaló függvények keretei által elfoglalt memória kicsi, és ezekben a keretekben az adatok nem változnak, akkor a befoglaló függvények keretei értékként adhatók át. Ez a funkció előre meghatározott bizonyos nyelvekhez (a legtöbb funkcionális nyelv és a Java a belső névtelen osztályok módszereihez). De olyan nyelvek esetében is, amelyek lehetővé teszik a befoglaló függvények adatainak megváltoztatását (például C# ), néhány hatékony fordító hibrid megközelítést valósít meg, amelyben a függvény veremkeretét a hívási verembe helyezik, ha a fordítónak sikerül kikövetkeztetnie programelemzéssel, hogy a függvény nem hoz létre növekvő funargokat, és egyébként a kupacban. A verem keretének a kupacra helyezése általában rontja a teljesítményt.

A csökkenő funarg probléma

A csökkenő funarg utalhat egy függvény állapotára is, amikor az nem fut. Mivel azonban a definíció szerint egy downstream funarg létezését az azt létrehozó függvény végrehajtási ideje korlátozza, a hívási veremben elhelyezhető egy verem keret neki. A felülről lefelé irányuló funars azonban a lezárások és keretek fastruktúráját foglalja magában, ami megnehezíti a program állapotára vonatkozó emberi következtetéseket.

A probléma olyan nyelvű programokban jelentkezik, amelyek lehetővé teszik a függvények paraméterként történő átadását, mint például a Pascal és az Algol 68 .

A felülről lefelé irányuló funarg probléma megnehezíti a tail rekurzió és a folytatást átadó kód hatékony fordítását .

Jegyzetek

  1. A FUNCTION funkciója a LISP-ben, vagy miért kell a FUNARG problémát környezeti problémának nevezni , Joel Moses, in: ACM SIGSAM Bulletin 17 (1970. július), pp. 13-27
  2. A FUNARG probléma megoldási javaslata , Erik Sandewall, in: ACM SIGSAM Bulletin 17 (1971. január), pp. 29-42