| Oberon | |
|---|---|
| Sprog klasse | imperativ , struktureret , modulær |
| Dukkede op i | 1986 |
| Forfatter | Niklaus Wirth |
| Type system | statisk , stærk |
| Blev påvirket | Modula-2 , Pascal |
| påvirket | Aktiv Oberon , Component Pascal , Go , Java [1] [2] , Modula-3 , Oberon-2 , Zonnon , Nim |
| Licens | BSD |
| Internet side | projectoberon.com |
Oberon er et programmeringssprog på højt niveau designet af Niklaus Wirth til at udføre programmer på operativsystemet af samme navn , forfattet af Niklaus Wirth og Jürg Gutknecht .
Programmer skrevet i programmeringssproget Oberon kræver en form for runtime-understøttelse - de har brug for en dynamisk loader og en centralt udført automatisk skraldeopsamler, hvortil Oberon-programmer har brug for et særligt driftsmiljø. Den sædvanlige måde at implementere det på er at tilføje et sæt biblioteker til systemet, der implementerer de nødvendige komponenter, selvom operativsystemet generelt ikke nødvendigvis behøver et separat operativsystem: det kan i sig selv være et operativsystem. Det er Native Oberon-systemerne til den originale Oberon og A2 til Active Oberon . I øjeblikket er der Oberon-kompilere til Java Virtual Machine-bytekoden og en CLI til .NET Virtual Machine .
Operativsystemer og miljøer til udførelse af programmer på sprog fra Oberon-familien, der udviklede sig fra det originale Oberon-system, er ETH Oberon, BlackBox Component Builder , WinOberon , A2 osv.
Oberon-0, Oberon-X og andre projekter blev udviklet på grundlag af Oberon [3] . Enkelheden af Oberon og tilgængeligheden af kildekoder til den originale implementering gør det nemt at tilpasse det til specielle klasser af problemer. Men alle disse Oberoner er meget tæt på hinanden, da den originale Oberon er meget enkel.
Programmeringssproget Oberon blev skabt af Niklaus Wirth i 1988 baseret på programmeringssprogene Modula-2 , Pascal og Algol-60 [4] .
Ifølge Wirth ønskede de oprindeligt at skrive systemet direkte på modulet, men de kom til den konklusion, at det skulle forfines og reduceres, hvilket førte til fremkomsten af Oberon [5] .
Målet med projektet ( Eng. Project Oberon ) af Niklaus Wirth og Jürg Gutknecht i 1986-1989 [6] var at skabe fra bunden af et synligt og pålideligt operativsystem til en enkeltbrugerarbejdsstation.
For at implementere dette projekt designede Niklaus Wirth i 1988 et generel programmeringssprog på højt niveau, også kaldet Oberon [7] .
I 1989 blev den første implementering af Oberon til NS32000-familien af processorer frigivet på ETH Zürich (ETH) . Det blev skabt som en del af Oberon-operativmiljøet. Denne compiler kræver mindre end 50 KB hukommelse, består af 6 moduler med en samlet volumen på omkring 4000 linjer og kompilerer sig selv på 15 sekunder på en computer med en NS32532-processor (clockfrekvens - 25 MHz).
Det er simpelthen umuligt at takke alle dem, der på den ene eller anden måde har drevet det, der nu hedder Oberon, med deres ideer. De fleste af ideerne kom fra at bruge og lære fra eksisterende sprog som Modula-2, Ada, Smalltalk og Cedar, som ofte advarede os om, hvad vi ikke skulle gøre.Niklaus Wirth [5]
Sproget beholdt hovedtrækkene i Modula- syntaksen og var en objektudvidelse . Dette gjorde det muligt at opgive mekanismen for variantposter Moduler, som er et tilbagetog fra den oprindelige stærke statiske typning , hvilket gjorde det muligt at indføre en automatisk hukommelseshåndteringsmekanisme - skraldindsamling : muligheden for at frigøre dynamisk allokeret hukommelse ved hjælp af en speciel operatør blev udelukket fra sproget, og i stedet indeholder selve runtime et modul A, der returnerer ubrugt hukommelse til systemet. Automatisk hukommelsesstyring er et middel til at forbedre pålideligheden af programmer med dynamiske datastrukturer, da det eliminerer menneskelige fejl, som for eksempel er typiske for sprog som C / C++ .
For at opnå den største pålidelighed og ydeevne af oversættelse, blev der foretaget en væsentlig forenkling af sproget ved at eliminere funktioner, der blev anset for unødvendige (baseret på erfaring med udvikling, implementering og brug af andre sprog), enten komplicerede compileren uden tilstrækkelig begrundelse med hensyn til ydeevne, eller var komplekse nok til at blive sendt til eksterne biblioteker, eller ikke kompatible med modularitet og automatiske hukommelsesstyringsmekanismer: variantposter , opregnede typer , rækketyper , generiske sæt , usigneret heltalstype, lokale moduler, definitionsmoduler, eksport lister, operator for, den tidligere version af with-sætningen, en speciel syntaks til at definere et hovedprogram. De rudimentære midler til at understøtte parallel programmering, som var tilgængelige i Modul-2, kom ikke ind i sproget, da det tjente et enkeltbrugeroperativsystem. Undtagelseshåndtering er blevet droppet for nemheds skyld .
Beskrivelsen af arrays er blevet forenklet (array-indekser kan kun være heltal og altid starte fra nul, ligesom C-sproget), brugen af pointere er begrænset - pointere kan kun eksistere på poster og arrays, kun det importerede modul er specificeret i import lister, og ved brug af importerede navne, en obligatorisk kvalifikation (eksplicit angivelse af navnet på eksportørmodulet). I artiklen "Fra Modula til Oberon" [5] forklarede Wirth i detaljer årsagerne til fjernelsen af hvert af elementerne.
Af hensyn til "tilstrækkeligt minimum" blev metoder (procedurer og funktioner forbundet med en type) ikke inkluderet i sproget som et eksplicit syntaktisk begreb, da denne mekanisme i sin mest generelle form er let at modellere ved at skabe felter af en proceduremæssig type i objekter (optegnelser på Oberon-sproget) og tildele dem procedurer svarende til metoderne. Objektorienteret programmering understøttes således i Oberon med minimale midler til at forenkle processen med kodeoversættelse og fremskynde denne proces.
Takket være ændringerne er Oberon blevet syntaktisk enklere. Beskrivelsen af dets syntaks passer på én side, den fulde beskrivelse af sproget tager omkring 20 sider, hvilket er halvt så meget som beskrivelsen af Modula-2 . Oberon er, hvis ikke minimal, så i det mindste et af de mindste universelle programmeringssprog på højt niveau.
Einsteins udtalelse blev valgt som epigrafen til beskrivelsen af den originale Oberon: "Gør det så enkelt som muligt, men ikke enklere end det . "
Defineret i følgende RBNF- forslag [8] :
Modul = MODULE id ";" [ ImportList ] Last Declared [ BEGIN Last Statements ] END id "." . ImportList = IMPORTER [ id ":=" ] id { "," [ id ":=" ] id } ";" . LastDeclared = { CONST { DeclaredConst ";" } | TYPE { Typedeclaration ";" } | VAR { DeclaredVar ";" }} { DeclaredProc ";" | ForwardDeclared ";" }. DeclaredConst = IdentDef "=" ConstExpression . TypeDeclare = IdentDef "=" Type . DeclaredVar = ListIdentifier ":" Type . DeclaredProc = PROCEDURE [ Receiver ] IdentDef [ FormalParam ] ";" Sidst erklæret [ BEGIN Sidste udsagn ] SLUT Ident . ForwardDeclare = PROCEDURE "^" [ Receiver ] IdentDef [ FormalParam ]. FormalParam = "(" [ FP Section { ";" FP Section }] ")" [ ":" SpecIdent ]. SectionFP = [ VAR ] id { "," id } ":" Type . Modtager = "(" [ var ] id ":" id ")" . Type = QualID | ARRAY [ ConstExpression { "," ConstExpression }] AF Type | OPTAG [ "(" QualIdent ")" ] FieldList { ";" Feltliste } END | PÅGØR TIL Type | PROCEDURE [ FormalParam ]. FieldList = [ ListIdent ":" Type ]. AfterOperators = Operatør { ";" Operatoren }. Operator = [ Notation ":=" Udtryk | Notation [ "(" [ ListExpression ] ")" ] | IF Expr THEN Statement Seq { ELSIF Expr THEN Statement Seq } [ ELSE Statement Seq ] END | CASE -udtryk for valgmulighed { "|" Variant } [ ELSE StatementSeq ] END | WHILE Express DO Statement Seq END | REPEAT StatementSeq INNTIL Udtryk | LOOP AfterStatements END | MED Guard DO Statement Seq END | AFSLUT | TILBAGE [ Express ] ]. Option = [ Option Labels { "," Option Labels } ":" StatementLast ]. VariantLabels = ConstExpression [ ".." ConstExpression ]. Guard = SpecId ":" SpecId . ConstExpression = Express . Udtryk = SimpleExpression [ Relation SimpleExpression ]. SimpleExpression = [ "+" | "-" ] Term { OperSlog Term }. Term \ u003d Multiplikator { OperMul Multiplikator }. Multiplikator = Notation [ "(" [ Listeudtryk ] ")" ] | nummer | symbol | streng | NIL | Sæt | "(" Udtryk ")" | " ~ " Multiplikator . Set = "{" [ Element { "," Element }] "}" . Element = Express [ ".." Express ]. Relation = "=" | "#" | "<" | "<=" | ">" | ">=" | IN | IS . OperSlog = "+" | "-" | ELLER . OperUmn = "*" | "/" | DIV | MOD | "&" . Designation = Qualifier { "." ident | "[" Listeudtryk "]" | "^" | "(" QualIdent ")" }. ListExpr = Udtryk { "," Express }. ListIdent = IdentDef { "," IdentDef }. QualID = [ identifikator "." ] ID . IdentDef = ident [ "*" | "-" ].Oberon-programmet er et sæt moduler. Generelt ser modulet sådan ud:
MODUL Navn ; IMPORT Importliste ; Definitioner ; BEGIN Udsagn END Navn .Importlisten bestemmer, hvilke moduler eksterne navne vil blive importeret fra . Definitioner omfatter definitioner af typer, procedurer, funktioner, variabler, konstanter. I dette tilfælde eksporteres definitionerne af navne markeret med en stjerne af dette modul, det vil sige, at de vil være synlige for andre moduler, der importerer dette. I Oberon-2 er det også muligt at markere navne med et minustegn, i hvilket tilfælde de eksporteres i skrivebeskyttet tilstand.
Modulets krop udføres, når den indlæses. I Component Pascal, inde i kroppen af et modul (i sektionen BEGIN..END), er det nu muligt at tilføje en sektion CLOSE:
BEGIN CLOSE- udsagn END- udsagn Navn .Her udføres sætningerne mellem BEGINog CLOSE, når modulet indlæses, og sætningerne mellem CLOSEog udføres, når END det fjernes fra hukommelsen. En sådan udvidelse er fundet nyttig til komponentprogrammer, der indlæser og aflæser moduler dynamisk .
De datatyper, der oprettes af programmøren, er begrænset til følgende sæt: array- ARRAY typer , record- RECORD typer , procedure-typer PROCEDURE , pointer-typer POINTER . En pointer kan kun erklæres til en matrix eller post.
Syntaksen for den interne del af programmet er ret traditionel og enkel. Sproget understøtter det traditionelle sæt af konstruktioner: betinget operator IF, valgoperator , CASEcyklusser (med forudsætning - WHILE, med postbetingelse REPEAT..UNTIL, ubetinget - LOOP). I lighed med modul-2 skelnes der mellem store og små bogstaver i identifikatorer, alle reserverede ord skrives med stort. Alle sprogkonstruktioner, undtagen en loop REPEAT..UNTIL, slutter med et nøgleord ENDog tillader indlejring i flere sætninger uden at bruge en sammensat sætning BEGIN..END. Naturligvis, som i Modul-2, er der ingen ubetingede spring.
Det objektorienterede programmeringsparadigme understøttes af rekordudvidelsesmekanismen (sproget har ikke et separat nøgleord til at beskrive klasser, såsom "klasse" eller "objekt", det anses for, at det sædvanlige begreb "rekordtype" er ganske tilstrækkelig). I det væsentlige er hver posttype en beskrivelse af klassen, og postens felter er datamedlemmer af klassen.
I den originale Oberon er der overhovedet ingen metoder (procedurer og funktioner forbundet med klassen ). Metodemekanismen kan bruges ved at deklarere felter af en proceduremæssig type i posten, som tildeles specifikke procedurer, når en instans af klassen oprettes . Kaldning af sådanne procedurer sker på den traditionelle måde at få adgang til postfeltet, som standard kender proceduren ikke til forekomsten af den klasse, den blev kaldt til (der er ingen lignende mekanisme thisi C++ eller Java), og hvis en sådan oplysninger er nødvendige for det, skal referencen til instansen sendes eksplicit (for eksempel gennem parameteren ). Manglen på eksplicit beskrevne metoder var en af egenskaberne ved den originale Oberon, som fremkaldte kritik fra programmører, der var vant til traditionelle hybridsprog. På den anden side giver mekanismen foreslået af Oberon dig mulighed for at implementere alt, der kan implementeres med traditionelle sprogmidler med metoder, og endnu mere - i Oberon kan hver forekomst af en klasse have sin egen version af en metode ( værdien af et felt af en proceduremæssig type), mens når man beskriver metoder som en del af en klasse, opererer alle instanser på en enkelt metodevariant. I Oberon 2 blev metoder stadig introduceret. Metoder er beskrevet separat fra posttypen, med angivelse af typen, de er knyttet til.
En ny posttype kan deklareres som en udvidelse af en eksisterende. I dette tilfælde er typen, der udvides, angivet i indgangsbeskrivelsen i parentes efter nøgleordet RECORD. En udvidet type modtager automatisk alle felter af den udvidede type og er (i Oberon 2) tilknyttet alle procedurer, der er forbundet med den udvidede type. Procedurerne knyttet til den nye type kan have samme signatur som procedurerne knyttet til den type, der udvides - dette sikrer, at metoderne i de afledte typer tilsidesættes. I Component Pascal , for at give fuld statisk kontrol over konsistensen af arvshierarkier (og derved genskabe det totale statiske skriveprincip, der adskilte den originale Oberon), er registreringer ikke som standard udvidelige, og metoder kan ikke tilsidesættes. Specielt introducerede nøgleord bruges til at kontrollere registreringsudvidelse og metodetilsidesættelse EXTENSIBLE, ABSTRACT, LIMITED, EMPTY. I dette tilfælde skal nyindførte metoder markeres med et nøgleord NEW(jf. den obligatoriske definition af nyindførte variable).
Oberon er rettet mod komponentorienteret softwareudvikling [9] . Indkapsling understøttes udelukkende på modulniveau - alle typer deklareret inde i modulet er absolut gennemsigtige for hinanden. Det, der er tilgængeligt fra andre moduler, er det, der er erklæret som eksporterbart i definitionen.
Polymorfi er tilvejebragt af metodemekanismen (både procedurefelter i Oberon og metoder i Oberon-2 opfører sig som virtuelle , i terminologien for de fleste hybride objektorienterede sprog), samt en udvidet WITH-konstruktion, der giver dig mulighed for at udføre forskellige grupper af udsagn, afhængig af om hvilken af de udvidede typer dets argument tilhører.
Der er ingen speciel konstruktørmekanisme i sproget. Den anbefalede metode til oprettelse og initialisering af objekter er beskrivelsen af generering af moduler og procedurer (fabrik i traditionel OOP-terminologi).
Et program i denne teknologi er et sæt relativt uafhængige komponenter (i dette tilfælde moduler), der har en intern struktur skjult for omverdenen og en klart defineret grænseflade. Moduler kan indlæses og aflæses dynamisk, mens programmet kører, systemet giver avancerede værktøj til kontrol af runtime-type, der giver dig mulighed for at skrive universelle databehandlingsalgoritmer, der ikke afhænger af de specifikke typer af disse data (f.eks. et bibliotek for arbejde med et DBMS kan give metoder, der skriver resultatet af en forespørgsel fra databasen til en post med en vilkårlig struktur, hvis sæt og typer af felter i denne post svarer til sættet og typer af felter i databasen).
I komponentparadigmet betragtes det som en uheldig arkitektonisk beslutning forbundet med den udbredte brug af implementeringsarv fra typer deklareret i en anden komponent, da dette fører til et fænomen kendt som "base type brittleness" - efter at et stort antal afledte typer er afledt fra basistypen (og nogle af dem kan endda være ukendte for udvikleren af basistypen), bliver eventuelle ændringer i implementeringen af basistypen ekstremt risikable, da de kan påvirke efterkommertyper på en uforudsigelig måde.
Det er kendt, at et af problemerne ved at bruge objektorienteret programmering i systemprogrammering er behovet for at have grupper af små klasser, der kan interagere uden yderligere overhead. Oberon har ikke dette problem - alle typer defineret i et modul ser hinanden, og det skaber ikke pålidelighedsproblemer, da modulet stadig er udviklet, testet og vedligeholdt som en helhed.
Et typisk system udviklet på Oberon er et sæt moduler med proceduremæssige grænseflader, hvorigennem moduler udveksler data, herunder objekter. Samtidig fungerer alle indkapslingsværktøjer kun i inter-modul interaktion, hvilket gør systemprogrammering ved hjælp af objekter praktisk.
Objektorienteret programmeringObjektprogrammeringsværktøjer fortolkes i Oberon som en naturlig udvikling af værktøjer til at arbejde med poster i et modulært system, mere præcist som et teknisk værktøjssæt til at løse et specifikt arkitektonisk problem: at sikre en effektiv "arbejdsdeling" mellem forskellige moduler, når der arbejdes. med dynamiske typer og datastrukturer: for eksempel kan arbejde med pointere i listen skjules (sammen med de tilsvarende felter) i ét modul, og definitionen og arbejdet med den specifikke "udfyldning" af listeelementerne kan specificeres i et andet (eller oftere andre). I denne forstand er Oberons objektprogrammeringsteknologi underordnet begrebet modularitet: her er det snarere et middel til at beskrive data end et middel til at bygge en applikationsarkitektur som helhed.
Ifølge Wirth [10] studerede udviklerne af Java -sproget, flere år før dets oprettelse, "Oberons kildekoder og i særdeleshed kildekoderne for Oberons skraldesamlere. Så rodede de Oberon med C-syntaks og kaldte det Java." Selvom man ikke kan kræve absolut nøjagtighed af ordlyden fra en mundtlig præsentation, tyder under alle omstændigheder den utvivlsomme lighed mellem Oberon og Javas ideologier (ønsket om minimalisme og stærk maskinskrivning, begrænsningen af multiple arv, automatisk hukommelsesstyring) at der er en vis konsensus om, hvilke værktøjer der skal udgøre kernen i et moderne alment programmeringssprog. Men hvis minimalisme forbliver på forkant i Oberon og dets direkte efterfølgere, har Java-udviklere taget vejen til omfattende opbygning af sprogets muligheder.
Selve sprogfamilien Oberon omfatter også Oberon-07 , Oberon-2 , Component Pascal ( Component Pascal ), Active Oberon , OberonScript osv.
Den originale version af Oberon ("klassisk Oberon") er den mest kortfattede, med det mindste antal nøgleord og syntaktiske konstruktioner. Det blev brugt som grundlag for at skabe en familie af sprog, som hver især udvider den klassiske i en eller anden retning eller adskiller sig fra den i nogle detaljer.
I 1992 er Niklaus Wirth og hans studerende Hanspeter Mössenböck nu professorer ved universitetet. Johannes Kepler i Linz - udgav en beskrivelse af en udvidet version af Oberon, kaldet Oberon-2 . Han er en raffineret udgave af den klassiske Oberon. Tilføjelserne til Oberon 2, og gjort meget sparsomt, er som følger:
På trods af udvidelsen af sproget er volumen af den formelle beskrivelse af syntaksen for Oberon-2 mindre end den for den klassiske Oberon på grund af optimeringen af syntaksbeskrivelsen. Der er en optimeringskompiler XDS [13] til Oberon-2; der er også en compiler [14] til Java bytecode .
ETH Oberon , hvis implementeringer er tilgængelige for mange computerplatforme.
Oberon SA er en version af Oberon-sproget udviklet af N. Wirth til Strong-ARM-processoren , der bruges i en ubemandet helikopter .
Baseret på erfaringerne fra udviklingen af Oberon SA udarbejdede N. Wirth i 2007 ændringer og tilføjelser til den klassiske Oberon [15] [16] for en strengere understøttelse af struktureret programmering end for eksempel i Oberon-2 eller Component Pascal. Den nye version af sproget fik navnet Oberon-07 [17] . Der er en oversættelse af "Programmeringssproget Oberon, Revision 1.11.2008" til russisk [18] . Men hvad angår understøttelse af objektorienteret programmering , følger Oberon-07-sproget ikke Oberon-2, men fortsætter den minimalistiske linje fra den klassiske Oberon, herunder manglen på understøttelse af procedurer forbundet med posttyper.
Oberon-07 har følgende hovedforskelle fra den klassiske Oberon:
Det australske firma CFB Software (Brisbane) ved University of Queensland har udviklet Astrobe IDE [21] til Oberon-07-sproget til NXP (Philips) ARM7-mikrocontrollere og syntaksdiagrammerne for Oberon-07-sproget [22] . som retningslinjer for stilen af programmer i Oberon-07 [23] .
Umiddelbart efter udgivelsen i 1992 blev Oberon-2 betragtet som en kandidat til rollen som sprogstandard (Oakwood Conference, Croydon, 1993), men den praktiske erfaring opnået med at skabe store softwaresystemer afslørede nogle svagheder ved innovationer og ønskværdigheden af yderligere raffinementer (hvilket endnu en gang understreger visdommen i den konservatisme, som Wirth udviste ved at definere den klassiske Oberon). Disse forbedringer blev foretaget i en variant af Oberon-2 kaldet Component Pascal og udgivet i 1999 af Oberon microsystems [24] , dannet i 1992 af Wirths studerende (Wirth blev selv medlem af bestyrelsen). Ligesom i overgangen fra Oberon til Oberon-2 er disse justeringer foretaget mest sparsomt [25] . Især understøtter sproget nu fuldt ud komponentorienteret programmeringsmetodologi . Takket være den sidste omstændighed er komponent Pascal i øjeblikket tilsyneladende den mest perfekte blandt de direkte efterkommere af den klassiske Oberon. Det kan dog reduceres ikke kun til en delmængde svarende til den originale Oberon, men også til en anden fuldgyldig minimalistisk delmængde, hvor arv og metodetilsidesættelse kun er tilladt for rene grænsefladetyper og metoder (defineret med ABSTRACT-attributten). Denne omstændighed afslører den noget mellemliggende karakter af Oberon-2.
Komponent Pascal tilføjer funktioner, der gør det muligt for udvikleren at have fuld kontrol over eksporttypeudvidelse og metodetilsidesættelse (EXTENSIBLE, ABSTRACT, NEW, EMPTY attributter, samt muligheden for begrænset "implementation-only" metodeeksport). Tilføjet modullegeme-fuldførelsesblok (CLOSE nøgleord) og foruddefineret tom FINALIZE-metode. Systemet med grundlæggende (elementære) typer er tilpasset Java-typer. En implicit strengtype er blevet introduceret. Oberon Microsystems, som definerede Component Pascal , udgav også BlackBox Component Framework og det visuelle programmeringsmiljø BlackBox Component Builder [26] , lille i størrelse og krævende for ressourcer, fuldstændig bygget på Component Pascal.
Efterfølgende blev BlackBox-compilatoren indbygget i Denia cross-platform programmeringsmiljøet , især til JBed real-time operativsystemet , skrevet udelukkende i Component Pascal.
Disse sprog kan allerede med god grund kaldes ikke udvidelser eller versioner af Oberon, men uafhængige sprog. De udvidede syntaksen betydeligt, introducerede konstruktioner til at beskrive de klassiske "egenskaber" (egenskaber) med læse/skrivekontrol, numeriske typer med en specificeret størrelse i bit. Indført understøttelse af aktive objekter, der udveksler meddelelser i formatet defineret af RBNF-beskrivelsen, undtagelseshåndtering [27] .