Type system

I informatikk definerer et typesystem hvordan et programmeringsspråk klassifiserer verdier og uttrykk i typer , hvordan disse typene kan manipuleres og hvordan de samhandler. En datatype indikerer et sett med verdier som har samme generiske betydning eller formål (selv om noen typer, for eksempel abstrakte datatyper og funksjonsdatatyper, kanskje ikke representerer verdier i det kjørende programmet). Typesystemer varierer betydelig mellom språk, med kanskje de viktigste variasjonene i deres egne implementeringer av kompileringstidssyntaks og kjøretidsoperasjon.

En kompilator kan bruke den statiske typen til en verdi for å optimalisere lagringen den trenger og valget av algoritmer for operasjoner på den verdien. For eksempel, i mange C -kompilatorer er "flyt"-datatypen representert som 32 biter , i samsvar med IEEE-spesifikasjonen for flytende tall med én presisjon . Så C bruker spesifikke flyttalloperasjoner på disse verdiene (flytepunktaddisjon, multiplikasjon, etc.).

Rekkevidden for datatypegrensene og formen for evalueringen påvirker "skrivingen" av språket. Et programmeringsspråk kan også assosiere en bestemt operasjon med forskjellige algoritmer for hver datatype i tilfelle polymorfisme . I matematikk og logikk er typeteori studiet av typesystemer, selv om de konkrete datatypesystemene til programmeringsspråk stammer fra de tekniske problemene med dataarkitekturer, kompilatorimplementering og design. av språk.

Grunnleggende

Tilordning av datatyper ( skriving ) gir mening til samlinger av biter. Datatyper har vanligvis assosiasjoner enten med verdier i minnet eller med objekter som variabler . Siden en hvilken som helst verdi ganske enkelt består av et sett med databiter , gjør maskinvaren ingen forskjell mellom minneadresse , instruksjonskode , tegn , heltall og flyttall . Datatyper informerer programmer og programmerere om hvordan disse bitene skal behandles.

Hovedfunksjonene som skrivesystemer tilbyr er:

Et program forbinder normalt hver verdi med en bestemt datatype (selv om en datatype kan ha mer enn én undertype). Andre enheter, for eksempel objekter, biblioteker , kommunikasjonskanaler, avhengigheter eller til og med datatyper selv, kan assosieres med en datatype. For eksempel:

Et typesystem , spesifisert i hvert programmeringsspråk, fastsetter måtene programmer kan skrives på og gjør enhver oppførsel utenfor disse reglene ulovlig.

Skrivesjekk

Prosessen med å kontrollere og håndheve grensene som pålegges av datatyper – skrivekontroll – kan skje enten ved kompilering (en statisk sjekk) eller ved kjøretid (en dynamisk sjekk). Hvis et språk sterkt håndhever skriveregler (dvs. tillater vanligvis bare automatiske datatypekonverteringer som ikke lekker informasjon), kan man referere til prosessen som sterkt skrevet ; hvis ikke, svakt skrevet .

Statisk skriving

Et programmeringsspråk sies å bruke statisk skriving når skrivekontrollen gjøres under kompilering, og ikke under utførelse. Eksempler på språk som bruker statisk skriving er C , C++ , Java og Haskell . Sammenlignet med dynamisk skriving gjør statisk skriving det mulig å fange opp skrivefeil raskere, og programkjøringen blir mer effektiv og sikker.

Dynamisk skriving

Et programmeringsspråk sies å bruke dynamisk skriving når typekontrollen utføres under utførelse i stedet for under kompilering. Eksempler på språk som bruker dynamisk skriving er Perl , Python og Lisp . Sammenlignet med statisk skriving, eller tidlig kobling, er dynamisk skriving mer fleksibel (på grunn av teoretiske begrensninger på avgjørbarheten til visse statiske programanalyseproblemer, som forhindrer samme grad av fleksibilitet som oppnås med dynamisk skriving). ), til tross for at den går langsommere og være mer utsatt for feil.

Kombinert statisk og dynamisk skriving

Noen statisk skrevet språk har en "bakdør" i språket som lar programmerere skrive kode som ikke er statisk sjekket. For eksempel har språk som Java og C-lignende språk en " tvungen rollebesetning " ; disse operasjonene kan være usikre ved kjøretid, fordi de kan forårsake uønsket oppførsel når programmet kjøres. Andre programmeringsspråk som C# bruker dynamiske datatypedeklarasjoner i et statisk miljø, noe som tillater nesten fullstendig fleksibilitet til et dynamisk språk i et statisk språk.

Tilstedeværelsen av statisk skriving i et programmeringsspråk betyr ikke nødvendigvis fravær av dynamiske skrivemekanismer. For eksempel bruker Java statisk skriving, men enkelte operasjoner krever kjøretidsstøtte for datatyper, som er en form for dynamisk skriving. Se programmeringsspråk for en videre diskusjon av samspillet mellom statisk og dynamisk skriving.

Statisk og dynamisk skrivekontroll i praksis

Valget mellom dynamiske og statiske skrivesystemer krever noen avveininger.

Statisk skriving sjekker for feil i datatyper under kompilering. Dette bør øke påliteligheten til de behandlede programmene. Imidlertid er programmerere ofte uenige om hvordan de vanligste datatypefeilene oppstår, og hvor stor andel av disse feilene som er skrevet som kunne ha blitt fanget opp med statisk skriving. Statisk skriving forfekter troen på at programmer er mer pålitelige når datatypene deres kontrolleres, mens dynamisk skriving peker på distribuert kode som har blitt testet for å være pålitelig og har et lite sett med feil. Verdien av den statiske skrivingen øker da etter hvert som skrivesystemet stivner. Tilhengere av sterkt typespråk som ML og Haskell har antydet at nesten alle feil kan betraktes som datatypefeil, hvis datatypene som brukes i et program er tilstrekkelig godt deklarert av programmereren eller utledet av kompilatoren. [ 1 ]

Statisk skriving resulterer vanligvis i raskere løpende kompilert kode. Når kompilatoren vet de eksakte datatypene som er i bruk, kan den produsere optimalisert maskinkode. Også kompilatorer på statisk skrevet språk kan finne snarveier lettere. Noen dynamisk skrevet språk som lisp tillater valgfrie datatypedeklarasjoner for optimalisering av nettopp denne grunnen. Statisk skriving generaliserer denne bruken. Se programvareoptimalisering

I motsetning til dette lar dynamisk skriving kompilatorer og tolker kjøre raskere, fordi endringer i kildekoden på dynamisk skrivede språk kan resultere i færre kontroller og mindre kode å gjennomgå. Dette reduserer også edit-compile-check- debug -syklusen .

Statisk skrevet språk som ikke støtter inferens (som Java) krever at programmereren erklærer datatypene som en metode eller funksjon kan behandle. Dette kan fungere som ekstra programdokumentasjon, som kompilatoren ikke vil tillate programmereren å ignorere eller drive ut av synkronisering . Imidlertid kan et språk skrives statisk uten å kreve en datatypedeklarasjon (eksempler inkluderer Scala og C#3.0), så dette er ikke en konsekvens av statisk skriving.

Dynamisk skriving tillater konstruksjoner som enkelte statiske skrivesystemer vil avvise som ulovlige. For eksempel Pythons eval -funksjon , som kjører vilkårlige data som kode. Dynamisk skriving er også mer egnet for overgangskode eller prototyping. Nyere utviklinger innen språk som Haskell (for eksempel generaliserte algebraiske typer) tillater statisk skrivede språk å kjøre kode fra datastrukturer på en sikker måte.

Dynamisk skriving gjør vanligvis metaprogrammering mindre omfattende. For eksempel krever generiske C++ mer beskrivende skriving enn tilsvarende i Ruby eller Python , nettopp fordi det er nødvendig å spesifisere typene som er involvert. [ referanse nødvendig ]

Kontrovers

Det er ofte konflikter mellom de som foretrekker sterk og/eller statisk skriving og de som foretrekker dynamisk, fri eller svak skriving. Den første gruppen tar til orde for tidlig feildeteksjon under kompilering og ytelsesgevinster ved kjøretid, mens den andre gruppen tar til orde for rask prototyping som er mulig med et dynamisk skrivesystem. [ 2 ]

Se også

Referanser

  1. Avhengige typer i praktisk programmering - Xi, Pfenning (ResearchIndex)
  2. Meijer, Erik og Peter Drayton. "Statisk skriving der det er mulig, dynamisk skriving når det er nødvendig: slutten av den kalde krigen mellom programmeringsspråk" . Microsoft Corporation. Arkivert fra originalen 16. februar 2007. 

Eksterne lenker