Arviointistrategia - ohjelmointikielen semantiikan säännöt, jotka määrittävät, milloin funktion argumentit ( menetelmä, toiminta, suhde) tulee arvioida ja mitkä arvot välitetään . Esimerkiksi call-by-worth/pass-by-reference -strategia määrää , että argumentit on arvioitava ennen kutsutun funktion rungon suorittamista ja että sille on annettava kaksi mahdollisuutta jokaiselle argumentille: nykyisen arvon lukeminen ja sen muuttaminen toimeksiantooperaattorilla [1] . Tämä strategia on samanlainen kuin -vähennysstrategia lambda-laskennassa, mutta siinä on eroja.
Käytännössä monien teollisten kielten ( Java , C# ) laskennallinen malli tiivistyy " kutsun maininnan/pass-by-reference " -strategiaan . Jotkut vanhemmat kielet, erityisesti vaaralliset kielet, kuten C++ , yhdistävät useita erilaisia soittomalleja. Historiallisesti " call by value " ja " call by name " juontavat juurensa 1950 - luvun lopulla luotuun Algol - 60 : een . Vain puhtaat toiminnalliset kielet, kuten Clean ja Haskell , käyttävät " tarpeesta kutsua ".
Huomautus - venäjänkielisessä kirjallisuudessa laskentastrategiaa kutsutaan myös " parametrien välitysmenetelmäksi ", " laskentamalliksi " tai " puhelumalliksi ". Viimeinen vaihtoehto voi aiheuttaa sekaannusta soittotavan kanssa . Termi " parametrien välitys " on virheellinen monissa laskentastrategioissa.
Tiukka arviointimalli tarkoittaa , että argumentit arvioidaan aina täysin ennen funktion soveltamista niihin.
Kirkon notaatiossa lausuntojen innokas arviointi vastaa tiukkaa toimintojen arviointia , ja tästä syystä tiukkaa arviointia kutsutaan joskus " innokkaaksi ". Useimmat olemassa olevat kielet käyttävät tiukkaa arviointia funktioille.
Applikatiivinen järjestys , myös “ vasemmalta oikealle, sisältä ulos ”, ( vasemman sisin ) [2] [3] tarkoittaa laskentastrategiaa , jossa alhaalta ylöspäin suuntautuva AST arvioi argumentit vasemmalta oikealle pelkistetyissä lausekkeissa.
Toisin kuin kutsu arvolla, aplikatiivinen arviointijärjestys vähentää termejä funktion rungossa niin paljon kuin mahdollista ennen sen soveltamista.
Tarkastellaksemme esimerkkiä laskelmista aplikatiivisessa järjestyksessä määrittelemme useita funktioita [4] :
neliö(x) = x * x neliöiden_summa(x, y) = neliö(x) + neliö(y) f(x) = neliöiden_summa(x + 1, x * 2)Kun lasketaan f(5):n arvoa, saadaan seuraava joukko substituutioita:
f(5) = neliöiden_summa(5 + 1, 5 * 2) = neliö(6) + neliö(10) = ((6 * 6) + (10 * 10)) = 36 + 100 = 136Call by value ( englanniksi call-by-value ) on laajimmin käytetty laskentastrategia, se voidaan nähdä useilla kielillä C :stä Schemeen . Kun sitä kutsutaan arvolla, argumenttilauseke arvioidaan ja tuloksena oleva arvo liitetään vastaavaan muodolliseen funktioparametriin (yleensä kopioimalla tämä arvo uuteen muistipaikkaan). Tässä tapauksessa, jos kieli sallii funktioiden määrittää arvoja parametreilleen, muutokset vaikuttavat vain näihin paikallisiin kopioihin, mutta funktiokutsun kohdalla näkyvät arvot pysyvät muuttumattomina palautuksen yhteydessä.
Itse asiassa kutsu arvojen mukaan ei ole yksi tietty kutsumalli, vaan malliperhe, jossa argumentit arvioidaan ennen kuin ne välitetään funktion runkoon. Useimmat kielet ( Common Lisp , Eiffel , Java ), jotka käyttävät kutsua arvon mukaan arvioivat funktion argumentteja vasemmalta oikealle, mutta jotkut arvioivat ne oikealta vasemmalle ja jotkut ( Scheme , OCaml , C ) eivät määritä arviointijärjestystä .
Piilotetut rajoituksetJoissakin tapauksissa termi " call-by-value " ei ole aivan oikea, koska välitetty arvo ei ole muuttujan arvo tavallisessa merkityksessä, vaan viittaus arvoon, jonka toteutus voi olla erilainen. Tämän seurauksena koodi, joka näyttää syntaktisesti arvokohtaiselta, voi toimia joko kutsun mukaan tai yhteiskäytönä , ja ohjelman käyttäytyminen riippuu kielen semantiikan hienovaraisista yksityiskohdista.
Syynä kutsun käyttämiseen on yleensä se, että kieli ei teknisesti tarjoa mahdollisuutta toimia monimutkaisilla tiedoilla yhtenä arvona - se edustaa sitä tietorakenteena, vaikka se saa sen näyttämään kovasti lähteen arvolta. koodi. Täysiarvon ja naamioituneen tietorakenteen välisen viivan tarkan sijainnin määrittäminen voi olla erittäin vaikeaa. C: ssä vektori (eli yksiulotteinen taulukko , jonka erikoistapaus on merkkijono) on tietorakenne, ja siksi sitä käsitellään viittauksena muistipaikkaan; rakenne on kuitenkin arvo, vaikka sen kentät ovat vektoreita. Maplessa vektori on taulukon erikoistapaus ja siten tietorakenne; kuitenkin lista (joka on rakennettu ja indeksoitu täsmälleen samalla tavalla) on arvo. Tcl käsittelee arvoja kahdella tavalla: arvoesitystä käytetään komentosarjatasolla ja kieli itse hallitsee sopivaa tietorakennetta tarpeen mukaan. Tietorakenteeseen tehdyt muutokset näkyvät arvossa ja päinvastoin.
Selitys, että kieli " välittää parametrit arvon mukaan, jossa arvo on viite " on melko yleinen (mutta sitä ei pidä sekoittaa kutsuun viittauksella); muuten sitä kutsutaan yhteiskäyttöpuheluksi . Tästä johtuen Javassa ja Visual Basicissa arvokutsut käyttäytyvät merkittävästi eri tavalla kuin arvokutsut C :ssä ja Pascalissa . Massiivisen tietorakenteen siirtäminen funktiolle C:ssä tai Pascalissa kopioi koko rakenteen (ellei argumentti itse asiassa viittaa tietorakenteeseen), mikä saattaa heikentää suorituskykyä merkittävästi; Muutokset rakenteen tilassa eivät kuitenkaan näy kutsukontekstissä. Javassa ja Visual Basicissa kopioidaan aina vain viittaus rakenteeseen, mikä on nopeaa, ja rakenteen muutos näkyy kutsupaikalla.
Kun funktio kutsutaan viittauksella ( eng. call-by-reference ) tai ohimenevällä viittauksella ( pass-by-reference ), funktio saa implisiittisesti viittauksen argumenttina käytettyyn muuttujaan sen kopion sijaan arvo.
Tämä tarkoittaa yleensä sitä, että funktio voi muokata (eli muuttaa tilan ) parametrina välitettyä muuttujaa, ja tämä vaikuttaa kutsukontekstiin. Siksi puhelua viitteellä voidaan käyttää viestintäkanavan muodostamiseen soitetun ja soittajan välille. Suoraan kutsuun viittauksella perustuva kieli tekee ohjelmoijan vaikeaksi seurata kaikkia funktiokutsun vaikutuksia, joten se voi olla buginen .
Monet kielet tukevat call-by-referencea muodossa tai toisessa, mutta harvat käyttävät sitä oletuksena, kuten Perl . Useat kielet, kuten C++ , PHP , Visual Basic .NET , C# ja REALbasic , käyttävät oletusarvoisesti kutsua arvon mukaan, mutta tarjoavat kutsulle erityisen syntaksin viittauksella. C++ esittelee lisäksi ainutlaatuisen call-by-reference-to- constant -strategian .
Joidenkin kielten tyyppijärjestelmät, jotka käyttävät arvon mukaan kutsua ja eivät suoraan tue kutsua viittauksella, tarjoavat mahdollisuuden määritellä eksplisiittisesti viittauksia (muihin objekteihin viittaavia objekteja), erityisesti osoittimia (objekteja, jotka ovat tietokoneen muiden objektien osoitteita) muisti). Niiden avulla voit simuloida kutsua viittauksella puhelun arvon semantiikan sisällä. Tällaista ratkaisua käytetään esimerkiksi C- ja ML-kielissä . Se ei ole itsenäinen arviointistrategia - kieli kutsuu edelleen arvon mukaan - mutta sitä kutsutaan joskus nimellä " call-by-address " ( call-by-address ) tai " pass-by-address " ( pass-by-address ) . . Turvattomilla kielillä, kuten C tai C++ , se voi johtaa muistin käyttövirheisiin , kuten nollaosoittimen viittaukseen, mikä vaikeuttaa ohjelman ymmärtämistä ja kielen oppimista. ML : ssä viittaukset ovat tyyppiturvallisia ja muistiturvallisia .
Läheisen vaikutuksen tarjoaa myös " call by co-use " -strategia, jota käytetään esimerkiksi Javassa , Pythonissa , Rubyssa .
Puhtaissa funktionaalisissa kielissä ei ole semanttista eroa kutsulla viittauksella ja kutsulla arvolla (koska niiden tietorakenteet ovat muuttumattomia ja funktiolla ei kuitenkaan ole tapaa muuttaa argumenttien arvoa), joten niitä kuvataan yleensä kutsuna arvolta. , vaikka monet toteutukset todella käyttävät kutsua tehokkuuden parantamiseksi.
Seuraava esimerkki esittää simuloidun kutsun viittauksella E-kielellä :
def modify( var p, &q ) { p := 27 # parametri välitetty arvo - vain paikallinen arvo muuttuu q := 27 # parametri välitetty viitteellä - muuttaa kutsussa käytettyä muuttujaa } ? var a := 1 # arvo: 1 ? var b := 2 # arvo: 2 ? muokkaa(a, &b) ? a # arvo: 1 ? b # arvo: 27Seuraava esimerkki havainnollistaa kutsun simuloinnin viittauksella C-kielellä . Kokonaislukutyyppiset muuttujat ja osoittimet välitetään arvon mukaan. Mutta koska osoitin sisältää ulkoisen muuttujan osoitteen, sen arvo muuttuu.
void Muokkaa ( int p , int * q , int * o ) { // kaikki parametrit, jotka välitetään arvolla p = 27 ; // vain paikallinen arvo muuttuu * q = 27 ; // muuttaa ulkoista muuttujaa, johon q * o = 27 osoittaa ; // muuta ulkoista muuttujaa, johon o osoitti } int main () { int a = 1 ; int b = 1 ; int x = 1 ; int * c = & x ; Muokkaa ( a , & b , c ); // 1. parametri - muuttujan a arvo // 2. parametri - muuttujan b osoite // 3. parametri - muuttujan c arvo, joka on muuttujan x osoite // b ja x muutetaan return ( 0 ); }call-by-sharing tai call-with-resource-sharing ( englanniksi call-by-sharing ), myös call-by-object ( call-by-object ), myös call-by-object-sharing tai call-with- share -object ( call-by-object-sharing ), tarkoittaa, että kielen arvot perustuvat objekteihin eivätkä primitiivityyppeihin , eli " wrapped " ("pakattu", eng. boxed ). Kun funktio kutsutaan yhteiskäytöllä, se saa kopion objektiviittauksesta . Itse objektia ei kopioida – se jaetaan tai jaetaan . Tämän seurauksena funktion rungossa olevan argumentin osoituksella ei ole vaikutusta kutsukontekstiin, mutta osoituksella argumentin komponentteihin on vaikutusta .
Yhteiskäyttökutsu otettiin ensimmäisen kerran käyttöön CLU :ssa vuonna 1974 Barbara Liskovin ja muiden ohjauksessa [5] .
Tätä strategiaa käytetään Pythonissa [6] , Iotassa [7] , Javassa (objektiviittauksille) , Rubyssa , JavaScriptissä , Schemessa , Ocamlissa , AppleScriptissa ja monissa muissa. Eri kieliyhteisöjen terminologia on kuitenkin erilainen. Esimerkiksi Python-yhteisö käyttää termiä "couse call"; Java- ja Visual Basic -yhteisöissä samaa semantiikkaa kuvataan usein nimellä " kutsun arvo, jossa "arvo" on objektiviittaus ; Ruby-yhteisössä he sanovat, että Ruby " käyttää kutsua viittauksella " - huolimatta siitä, että puhelusemantiikka näillä kielillä on identtinen.
Muuttumattomien objektien kohdalla käyttökutsun ja kutsun mukaan ei ole eroa, paitsi että nämä objektit ovat identtisiä . Yhteiskäyttökutsun käyttö on vaihtoehto tulo/lähtöparametreille [8] - parametrin muuttaminen ei tarkoita parametrin määrittämistä ; parametria ei kirjoiteta päälle , vaan se muuttaa tilaa säilyttäen identiteettinsä.
Esimerkiksi Pythonissa listat ovat muuttuvia objekteja, joten:
def f ( l ): l . liitä ( 1 ) m = [ ] f ( m ) tulosta m- tulostaa " [1]", koska argumenttia " l" on muutettu.
Seuraava esimerkki osoittaa eron muutoksen ja määrityksen välillä. Koodi näin:
def f ( l ): l += [ 1 ] m = [] f ( m ) tulosta m- tulostaa " [1]", koska operaattori " l += [1]" käyttäytyy kuten " l.extend([1])"; mutta samanlainen koodi:
def f ( l ): l = l + [ 1 ] m = [] f ( m ) tulosta m- tulostaa " []", koska operaattori " l = l + [1]" luo uuden paikallisen muuttujan argumentin muuttamisen sijaan [9] .
Seuraavan ohjelman käyttäytyminen osoittaa laatikollisten arvojen ja käyttökutsun semantiikan:
x = [[]] * 4 x [ 0 ] . liittää ( 'a' ) x [ 1 ] . liittää ( 'b' ) x [ 2 ] . liitä ( ' c ' ) tulosta ( x ) >> [[ 'a' , 'b' , 'c' ], [ 'a' , 'b' , 'c' ], [ 'a' , 'b' , 'c' ], [ 'a' , 'b' , 'c' ]]" x = [[]] * 4"-operaattori luo tyhjän luettelon (kutsutaanko sitä " l") ja sitten uuden luettelon ( joka liittyy tunnisteeseen " x"), jossa on neljä elementtiä, joista jokainen on viittaus " l", eli " x = [ l, l, l, l ]”. Myöhemmät kutsut listan " x" eri elementteihin muuttavat objektia " l". Sama tapahtuu tulostettaessa luetteloa " x": koska se koostuu neljästä viittauksesta " l", niin " " koostumus ltulostetaan neljä kertaa.
call - by -copy-restore , myös kopioi - in copy-out ( copy-in copy-out ), myös call-by-value-in-result ( call-by-value-result ) tai call -by-value -return , kuten sitä kutsutaan Fortran - kieliyhteisössä , on erityinen call-by-reference -tapaus , jossa annettu viite on ainutlaatuinen kutsuvan kontekstin kannalta. Tämä vaihtoehto on mielenkiintoinen moniprosessorijärjestelmien ja etäproseduurikutsujen yhteydessä : jos funktioparametri on linkki, johon toinen suoritusprosessi pääsee käsiksi, sen sisältö voidaan kopioida uuteen linkkiin, joka ei ole enää käytettävissä; kun funktio palaa, tämän uuden linkin muutettu sisältö kopioidaan alkuperäiseen linkkiin ("palautettu").
Call-by-copy-restoren semantiikka eroaa myös kutsusta viittauksella, jos kaksi tai useampi funktion argumentti on toistensa aliaksia, eli viittaa samaan muuttujaan kutsukontekstissa. Viittauspuhelun tapauksessa yhden muuttaminen tarkoittaa toisen vaihtamista. Kopiointi-palautus-kutsu estää tämän välittämällä eri kopioita funktiolle, mutta kutsukontekstin tulos on määrittelemätön, koska se riippuu siitä onko takaisinkopiointi samassa suunnassa (vasemmalta oikealle vai oikealle). -vasemmalla) kuten ennen haastetta.
Jos viite välitetään alustamattomana, tätä arviointistrategiaa voidaan kutsua kutsun mukaan .
Osittaisella arvioinnilla ( englanniksi partial assessment ) voidaan tehdä laskelmia käyttämättömässä funktiossa. Kaikki osalausekkeet, jotka eivät sisällä sitomattomia muuttujia, arvioidaan, ja tunnetuilla argumenteilla varustettujen funktioiden sovelluksia vähennetään. Kun sivuvaikutuksia esiintyy , täydellinen osittainen arviointi voi tuottaa ei-toivottuja tuloksia, joten osittaista arviointia tukevat järjestelmät suorittavat ne vain puhtaille ilmauksille (ilmaisuille ilman sivuvaikutuksia) funktioissa.
Ei -tiukka arviointimalli tarkoittaa , että argumentteja ei arvioida ennen kuin niiden arvoa käytetään funktion rungossa.
Ei-tiukka funktioiden arviointi vastaa operaattoreiden laiskaa arviointia kirkon merkinnöissä , ja siksi ei-tiukkaa arviointia kutsutaan usein " laiskaksi ".
Useilla kielillä ( C , C++ jne.) Boolen lausekkeilla on ei-tiukka arviointijärjestys , jota kutsutaan venäjänkielisessä kirjallisuudessa " oikosulkuarviointiksi " , jossa laskelmat pysähtyvät heti, kun tuloksesta tulee yksiselitteisesti ennustettavissa - esimerkiksi arvo " true " disjunktiossa, " false " konjunktiossa ja niin edelleen. Haaraoperaattoreilla on usein myös laiska arviointisemantiikka, eli ne palauttavat koko operaattorin tuloksen heti, kun yksiarvoinen haara luo sen.
Normaali arviointijärjestys ( esim. Normaali järjestys ; myös " laskenta vasemmalta oikealle, ulkopuolelta sisälle ", vasen uloin ) on laskentastrategia, jossa sulkeva lauseke pienennetään kokonaan ja käytetään funktioita ennen argumenttien arviointia.
Toisin kuin normaalissa järjestyksessä, kutsu-nimellä-strategia ei arvioi argumentteja ja lausekkeita funktioissa, joita ei kutsuta.
Esimerkiksi arvo f(5) aiemmin määritellylle funktiolle f normaalissa järjestyksessä arvioituna antaa seuraavan joukon substituutioita [4] :
f(5) = neliöiden summa (5 + 1, 5 * 2) = neliö(5 + 1) + neliö (5 * 2) = ((5 + 1) * (5 + 1)) + (( 5 * 2) * (5 * 2)) = (6 * 6) + (10 * 10) = 36 + 100 = 136Kutsu-by-name- strategiassa argumentteja ei arvioida ennen funktion kutsumista. Sen sijaan ne korvataan suoraan funktion rungossa (käyttämällä substituutiota, joka estää n sieppaamisen ) ja sitten arvioida vaatimuksen sijasta. Jos argumenttia ei käytetä funktion rungossa, sitä ei arvioida ollenkaan; jos sitä käytetään useita kertoja, se lasketaan uudelleen jokaisen esiintymän kohdalla (katso Jensenin temppu ).
Soita nimellä on joskus parempi kuin arvon mukaan. Jos argumenttia ei käytetä funktion rungossa, nimellä kutsuminen säästää aikaa, koska sitä ei arvioida, kun taas kutsuminen arvolla tarkoittaa väistämätöntä arviointia. Jos argumentti on päättymätön arviointi , hyöty on valtava. Kuitenkin, kun käytetään argumenttia, nimellä kutsuminen on usein hitaampaa, koska se vaatii niin sanotun " thunk " luomisen.
Ensimmäistä kertaa nimikutsua käytettiin Algol-60- kielellä . .NET -kielet voivat simuloida kutsuja nimen mukaan käyttämällä delegaatteja tai Expression<T>-parametreja. Jälkimmäisessä tapauksessa funktio vastaanottaa AST :n . Eiffel - kieli toteuttaa agentteja, jotka ovat toimintoja, jotka suoritetaan pyynnöstä.
Call -by-need on muistiin tallennettu call-by- name -muunnelma , jossa argumentin arvo tallennetaan myöhempää käyttöä varten , jos argumentti arvioidaan . " Kielen puhtauden " tapauksessa ( sivuvaikutusten puuttuessa ) tämä tuottaa saman tuloksen kuin nimellä kutsuminen; ja tapauksissa, joissa argumenttia käytetään kahdesti tai useammin, kutsuminen on lähes aina nopeampaa.
Koska arvioidut lausekkeet voivat olla hyvin syvälle sisäkkäisiä, call-by-need-kielet eivät yleensä tue sivuvaikutuksia (kuten tilamuutoksia ) suoraan, ja niitä on emuloitava monadeilla (kuten Haskellissa ) tai ainutlaatuisilla tyypeillä kuten Clean -ohjelmassa). kieli ). Tämä eliminoi laiskan arvioinnin arvaamattoman käyttäytymisen, kun muuttujien arvoja muutetaan ennen niiden käyttöä.
Call-of-need -semantiikan yleisin toteutus on laiska arviointi , vaikka muitakin muunnelmia on, kuten optimistinen arviointi .
Haskell on tunnetuin kieli, joka käyttää call-by-need. R käyttää myös eräänlaista call-by-need -toimintoa. .NET -kielet voivat simuloida puhelua tarvittaessa käyttämällä Lazy<T>.
Kutsu-makrolaajennus on samanlainen kuin kutsu-nimellä, mutta käyttää tekstinkorvausta ei-kaappaavan korvaamisen sijaan. Huolimattomasti käytettynä makrokorvaus voi johtaa muuttujien sieppaamiseen ja ei-toivottuun ohjelman toimintaan. Hygieeniset makrot poistavat tämän ongelman tarkistamalla ja tarvittaessa korvaamalla varjostetut ei-parametrimuuttujat.
Täydessä β-pelkistuksessa mitä tahansa funktion sovellusta voidaan vähentää (korvaamalla argumentti funktion runkoon, käyttämällä substituutiota estämään kaappaaminen milloin tahansa. Tämä voidaan tehdä myös käyttämättömän funktion rungossa .
Kutsu tulevalla tai rinnakkaiskutsulla on rinnakkaisarviointistrategia : tulevaisuuden arvot arvioidaan rinnakkain muun ohjelman kanssa . Paikoissa, joissa vaaditaan käyttöarvo, pääohjelma blokkaa, kunnes laskenta on valmis, jos se ei ole vielä valmis.
Tämä strategia on ei-deterministinen, koska laskelmat voidaan suorittaa milloin tahansa tarkoituksen luomishetken (jossa lauseke annetaan) ja sen arvon käytön välisenä aikana. Se on samanlainen kuin tarpeen mukaan, sillä arvo arvioidaan vain kerran ja arviointia voidaan lykätä siihen asti, kun arvoa todella tarvitaan, mutta se voi alkaa aikaisemmin. Lisäksi, jos kohdearvoa ei enää tarvita (esimerkiksi funktion rungon paikallinen muuttuja arvioitiin ja funktio lopetettiin), arviointi voidaan keskeyttää.
Jos tavoitteet toteutetaan prosessien ja säikeiden kautta, kohteen luominen koodissa synnyttää uuden prosessin tai säikeen, arvon saaminen synkronoi sen pääsäikeen kanssa ja kohteen arvioinnin suorittaminen tarkoittaa sen arvon laskeneen prosessin tappamista.
Optimistinen arviointi on toinen muunnelma call-by-need, jossa funktion argumentti arvioidaan osittain jollekin varatulle ajanjaksolle (joka voidaan konfiguroida ohjelman suorituksen aikana), jonka jälkeen laskelmat keskeytetään ja funktiota käytetään kutsun avulla. tarpeen mukaan. Tämä lähestymistapa vähentää laiskalle arvioinnille ominaisia aikaviiveitä ja tarjoaa samat tuoteominaisuudet.