| Zonnon | |
|---|---|
| Sprog klasse | imperativ , strukturel , modulær , objektorienteret , flertrådet |
| Udførelsestype | kompileret |
| Dukkede op i | 2000 |
| Forfatter | Jürg Gutknecht [1] |
| Filtypenavn _ | .znn |
| Frigøre | 1.3.0 ( 9. november 2012 ) |
| Type system | statisk , stærk |
| Større implementeringer | ETHZ |
| Blev påvirket | Aktiv Oberon |
| Licens | MS-PL |
| Internet side | zonnon.org |
| Platform | .NET |
Zonnon er et alment programmeringssprog baseret på Modula-2 sproget, der understøtter aktive objekter introduceret i Active Oberon . Sproget introducerede et nyt programmeringsparadigme - kompositionsmodellen. Der bruges skraldopsamling , syntaktiske værktøjer til objektprogrammering, organisering af parallel computing, redefinering af operatører og undtagelseshåndtering er indeholdt. Sproget er designet af Jürg Gutknecht . I den moderne version af ETH -kompileren har sproget evnen til at løse lineære algebraproblemer med en syntaks svarende til matlab [2] [3] . Sprogkompileren er den første, der er skabt helt uden for Microsoft og fuldt integreret i Visual Studio sammen med andre .NET -platformsprog . [fire]
Projektet kom ud af deltagelse af forskere fra det schweiziske føderale institut for teknologi ( ETH ), Oberon-specialister inden for rammerne af projekt 7 (projekt 7), et initiativ fremsat i 1999 af Microsoft Research for at studere sproget for kompatibilitet med NET-platform i årene (1999-2002). [5] Forfatteren til sproget er Jurg Gutknecht, ETH-professor, kollega til Niklaus Wirth og hans medforfatter om Oberon -sproget . Zonnon-projektet blev udviklet i begyndelsen af 2000'erne i Zürich ved ETH . Målet med projektet var at skabe et alment programmeringssprog på højt niveau med den enkleste og klareste syntaks, men samtidig have tilstrækkelige evner til at udvikle software af enhver kompleksitet.
Zonnon-projektet kan ikke betragtes som en fortsættelse af rækken af sprog Pascal - Modula - Oberon - Oberon-2 - Komponent Pascal. Det er snarere en parallel gren , adskilt fra den nævnte linje et sted på niveau med Modula - Oberon. Den umiddelbare forfader til Zonnon er Active Oberon , udviklet med deltagelse af den samme Jürg Gutknecht. Hvis Niklaus Wirth, da han oprettede Oberon, forenklede Modula-2 så meget som muligt og fjernede alt, hvad der blev anset for ikke at være for nødvendigt, så tog skaberne af Zonnon-sproget en mere traditionel vej - de beholdt de fleste af funktionerne i Modula- 2 og endda returneret noget fra Pascal, og også suppleret sproget med flere nye koncepter og mekanismer.
Zonnon er ifølge tilhængerne af dette projekt enklere og mere kraftfuld end sprog som Ada, Java og C# [6] . Den er designet til nemt og effektivt at programmere parallelle systemer ved hjælp af de nye multi-core processorer, der vil dominere industrien i et årti.
Sproget skelner mellem store og små bogstaver - forskellen i tilfælde af bogstaver i identifikatorer fører til deres forskel. Et originalt træk er foretaget - nøgleord (reserverede) er reserveret, når du skriver enten alle bogstaver med store eller alle bogstaver med små bogstaver. Det vil sige, acceptog ACCEPT er nøgleord, men her AcCePt er blot en gyldig identifikator.
Der er 51 nøgleord på sproget (skrives enten kun med små eller kun med store bogstaver):
accept | aktiviteter | række | som | afvente | begynde | af | sag | konst | definition | div | gøre | andet | elsif | ende | undtagelse | exit | falsk | for | hvis | implementering | redskaber | import | i | er | lancering | sløjfe | mod | modul | ny | nul | objekt | af | på | operatør | eller | procedure | modtage | rekord | justeringer | gentag | tilbage | selv | send | derefter | til | sandt | type | indtil | var | mens
Af funktionerne kan man bemærke brugen af tegnet #som et symbol på operationen "ikke lige" (som i modul-2), såvel som tilstedeværelsen af operationen ** - "eksponentiering", - vendt tilbage til tjeneste efter mange år glemsel fra Fortran -sproget .
Sproget inkluderer et sæt primitive typer - flere numeriske typer, inklusive et heltal uden fortegn, flere rigtige, en strengtype (standardsprogværktøjer behandler strenge som ikke-modificerbare), tegn og boolesk. Områdetyper blev opgivet, men opregningstyper blev bibeholdt og brugt aktivt. Sættypen ( SET) er blevet bibeholdt, men er blevet mindre generisk - sæt kan nu kun bestå af heltal i intervallet fra nul til en eller anden implementeringsdefineret øvre grænse. Primitive typer og sæt kan bruges i et program med størrelsesmodifikatorer - hvis et tal i beskrivelsen af et objekt eller objekt følger typenavnet i krøllede parenteser, opfattes det som antallet af bits, der skal allokeres til værdien. Denne funktion (mere præcist de tilladte specifikke størrelsesværdier for hver af typerne) er dog systemafhængig, så brugen kan ikke anbefales i programmer, der hævder at være bærbare.
Arrays er beskrevet på samme måde som i Oberon - en array-type kan have en ubegrænset størrelse i ethvert sæt af dimensioner; når du opretter et rigtigt array, angives dets dimensioner eksplicit. Array-indekser kan enten være heltal (den nedre grænse er altid nul) eller opregnet.
Programmets generelle opbygning, moduler, modulets opdeling i et definitionsmodul og et implementeringsmodul, reglerne for skrivning af syntaktiske konstruktioner er lånt fra Modula-2 praktisk talt uden ændringer. Den "lange" konstruktion af den betingede operator IF-THEN-ELSIF-ELSE-END er understøttet, alle typer cyklusser tilgængelige i modulet: REPEAT-INTIL, WHILE, FOR, LOOP, CASE-valgkonstruktion. Fra Pascal blev de standard primitive I/O-operationer returneret til sproget Write, WriteLn, Read, ReadLn(som blev flyttet til standardbiblioteket i Modul-2 ).
Derudover har sproget:
Den vigtigste konceptuelle innovation af Zonnon, sammenlignet med Modula og Oberon, var introduktionen af aktive objekter. I de fleste programmeringssprog er et objekt blot en samling af data og behandlingsmetoder, der bruges af programmet efter behov. Aktive objekter har desuden deres egen adfærd, det vil sige, at hvert aktivt objekt har sin egen uafhængige udførelsestråd, som interagerer med andre tråde gennem sprogudvekslingsværktøjer i henhold til de protokoller, der er beskrevet for dem. I Zonnon blev det muligt at beskrive aktive objekter og rækkefølgen af deres interaktion med sproglige midler, hvilket gør det muligt om nødvendigt at danne et program som et sæt af selvstændigt arbejdende og interagerende aktive objekter.
Dette program beregner summen af to tal indtastet fra tastaturet.
Zonnon bruger kompositoriske arvemodeller baseret på aggregering. Typisk består et objekt (eller modul) af en række funktionelle komponenter, som hver især præsenterer sig for klienter i form af en abstrakt definition. Et sæt definitioner såvel som et objekts egen grænseflade (det vil sige samlingen af alle offentlige elementer af et objekt) udgør grænsefladen mellem et objekt og dets klienter. Dette giver dig mulighed for at realisere fordelene ved modul- og komponentprogrammering, og, hvad der er vigtigt, at være i stand til at understøtte enkelt og multipel nedarvning (uden ulemperne ved at implementere sidstnævnte i C ++), polymorfi, forfining og aggregering, delegering på niveau af metodesignaturer.
Det er næppe muligt entydigt at definere visse træk ved sproget som fordele og ulemper – en sådan vurdering er i høj grad afhængig af evaluatorens syn. I denne forbindelse ville det være passende at sammenligne Zonnon med sprog tæt på det.
Sammenlignet med Pascal og Modula-2 er Zonnon blevet meget mere kraftfuld, men samtidig mere voluminøs og mere kompleks. Stigningen i kraft blev opnået på grund af inddragelsen af nye syntaktiske konstruktioner. Parallelle behandlingsfaciliteter (i tilfælde af Zonnon er disse ikke kun de syntaktiske konstruktioner i sig selv, men også det generelle princip om at konstruere programmer som sæt af aktive objekter) giver dig mulighed for at overføre rutineoperationer til compileren. Bevarelsen af det modulære princip om programmering gør det muligt at skrive programmer på én gang uden brug af objektorienteret programmering , hvilket er vigtigt for uddannelsesformål. En ny kompositionsmodel er blevet indført, men OOP-tilhængere kan også bruge objekter. Der er indført undtagelseshåndteringsfaciliteter. Den komparative evaluering af sprog vil afhænge af, hvor betydelige disse to fordele betragtes.
Der er forskellige meninger om værktøjer til parallelbehandling: Nogle teoretikere og praktikere mener, at parallelle programmeringsværktøjer slet ikke bør introduceres i sproget, og støtte fra systembiblioteker er ganske nok for dem, andre påpeger, at sådanne biblioteker bør være absolut standard, det vil sige stadig blive en del af sproget, ellers vil programmer, der bruger dem, miste portabilitet (på den anden side er portabilitet egentlig ikke nødvendigt så tit). Under alle omstændigheder, for en programmør, er værdien af Zonnons parallelle behandlingsmekanismer i høj grad bestemt af, i hvilket omfang han er klar til at acceptere modellen af aktive objekter, som sproget foreslår som programmets hovedelement.
Der er heller ingen konsensus om mekanismen til håndtering af undtagelser. Niklaus Wirth nægtede at indføre en sådan mekanisme i Oberon, idet han anså den for ubrugelig, da Oberon-systemet, som dette sprog blev udviklet til, ikke har brug for det. Generelt er der en opfattelse af, at de fleste problemer med programmers reaktion på mulige fejl er fuldstændig løst uden undtagelseshåndtering, og denne mekanisme er ikke gratis - som regel skal du betale for muligheden for at fange enhver fejl med programmets ydeevne . På den anden side er undtagelseshåndtering bekvemt og er nu blevet almindeligt, og ydeevnetab er ikke så store (eller hastighedskravene er ikke så kritiske), at de giver afkald på bekvemmelighed ved udvikling.
De resterende innovationer fra Zonnon, især en mere udviklet OOP-syntaks, grænseflader, indeksere, egenskaber, operatøromdefinering, bør næppe betragtes som fundamentale. På den ene side komplicerer de sproget, og alt, hvad de giver dig mulighed for, kan gøres næsten lige så nemt uden dem. På den anden side skal det bemærkes, at disse midler i dette tilfælde blev gennemført ganske økonomisk. Når alt kommer til alt, hvis vi sammenligner Zonnon med Object Pascal, som udviklede sig tilnærmelsesvis efter samme skema - og supplerer kildesproget med nye moderigtige mekanismer, kan vi se, at Zonnon er på samme niveau med Object Pascal med hensyn til muligheder, og omgår det i parallelle bearbejdningsværktøjer, men forbliver stadig enklere .
Implementeringen af sproget lige fra begyndelsen gik ikke ad vejen med at skabe sit eget integrerede udviklingsmiljø og supportmiljø, som i tilfældet med Oberon-sproget, men langs integrationsvejen med .NET-platformen udgivet og vedligeholdt af Microsoft. Denne tilgang gav en stigning i implementeringshastigheden ved at eliminere udviklingen af sit eget miljø og bibliotekssystem og gav også automatisk programmer adgang til applikations- og systembibliotekerne i .NET-miljøet. Ulemperne ved denne implementeringsmulighed inkluderer udviklingens afhængighed af ekstern software, som ikke er under sprogimplementatorens kontrol.
Inden for den samme .NET-implementering er der dog en variant af et cross-platform udviklingsmiljø, der er integreret i Eclipse og bruger den gratis Mono -implementering af .NET, der kan fungere under Linux.
Til Windows er der også det enkleste native udviklingsmiljø ETH Zonnon Builder , som inkluderer en teksteditor med syntaksfremhævning, projektbygningsværktøjer og simple versionskontrolværktøjer.
Den første compiler blev oprettet på ETH til Microsoft .NET platformen af Evgeny Zuev. I 2005 blev der også skabt en softwarepakke, der integrerer en compiler og et CASE-system, der understøtter designet af Zonnon-programmer ved at konstruere diagrammer i UML 2.0 sproget i Microsoft Visual Studio .NET udviklingsmiljøet. Det resulterende værktøj understøtter standarden for MS Visual Studio .NET softwareudviklingscyklus i Zonnon-sproget ved hjælp af UML, inklusive den omvendte konstruktion af UML-beskrivelsen i henhold til projektkoden.
| Objektorienterede sprog | |
|---|---|
| Kompileret | |
| Scriptet |
|
| Begge forestillinger | |