Mange mennesker har problemer eller frustrasjoner over programmeringsspråkene de bruker hver dag. Noen vil at ting skal håndteres mer abstrakt, mens andre misliker implementeringsfunksjoner de skulle ønske var "standard". Enten du er en IT -profesjonell eller bare en hobbyist, kan det hende at du mange ganger vil finne deg et nytt programmeringsspråk.
Trinn
Trinn 1. Bli kjent med teknologien
Du kan ikke lage et programmeringsspråk hvis du ikke vet hvordan du bruker en datamaskin.
Trinn 2. Bli kjent med terminologien
Kompilatorforfattere bruker ofte ukjent terminologi. Les om kompilatorer før du fortsetter. Sørg for å vite alt du trenger å vite.
Trinn 3. Bestem hvilket problem språket ditt løser
Løser det et domenespesifikt problem, eller er det et generelt språk?
Trinn 4. Tenk på semantikken i språket ditt og begrepene om det
- Kommer du til å tillate direkte peker tilgang eller ikke?
- Hva er datatypene for språket ditt?
- Er det et statisk eller dynamisk språk?
- Hva er minnemodellen din? Kommer du til å bruke en søppelsamler eller manuell minnestyring? (Hvis du bruker en søppelsamler, må du forberede deg på å skrive en eller tilpasse en eksisterende til språket ditt.)
- Hvordan skal vi håndtere samtidighet? Kommer du til å bruke en enkel gjeng/låsemodell eller noe mer komplekst som Linda eller skuespillermodellen? (Siden datamaskiner i dag har flere kjerner.)
- Er det primitive funksjoner innebygd i språket, eller kommer alt fra et bibliotek?
- Hva er paradigmet eller paradigmene til språket ditt? Funksjonell? Objekt orientert? Prototype (som JavaScript)? Aspektorientert? Malorientert? Eller noe helt nytt?
- Hvordan skal språket ditt grensesnittet mot eksisterende biblioteker og språk (hovedsakelig C)? Dette punktet er viktig hvis du bygger et domenespesifikt språk.
- Til slutt vil noen av svarene på disse spørsmålene bli besvart av det andre trinnet, og vil hjelpe deg med å svare på det neste trinnet.
Trinn 5. Tenk på noen spesifikke oppgaver som noen ønsker å kunne utføre med språket ditt
For eksempel kan det være 'de vil lede en robot til å følge en linje' eller 'de vil kanskje lage relativt bærbare skrivebordsprogrammer i den' eller 'de vil kanskje lage webapplikasjoner med den'.
Trinn 6. Eksperimenter med syntaksideer (teksten på språket) for eksemplene ovenfor
Vær forsiktig med å beholde språket ditt i den kontekstfrie språkkategorien eller noe inni det. Parsergeneratoren din, og du vil sette pris på det senere
Trinn 7. Skriv ut en formell grammatikk for syntaksen
Trinn 8. Bestem om språket skal tolkes eller kompileres
Dette betyr at brukeren i den tolkede verden vanligvis vil redigere programmet i et redigeringsprogram og kjøre det direkte på tolken; mens i den kompilerte verden, vil brukeren redigere programmet, kompilere det, lagre den resulterende kjørbare et sted og kjøre det.
Trinn 9. Skriv frontend -skanneren og parseren, eller finn et verktøy som hjelper deg med dette
Tenk også på hvordan kompilatoren/tolken din vil advare brukeren din om feilaktige programmer og syntaksfeil
Trinn 10. Bruk parserinformasjonen til å skrive objektkoden eller en mellomrepresentasjon
La analysatoren lage en AST, deretter opprette objektkoden fra AST ved hjelp av tre adressekoder eller storebror SSA, deretter lage en symboltabell for å definere funksjonene dine, globale variabler, etc.
Avhengig av språket ditt kan det også være lurt å lage virtuelle pekertabeller eller informasjonstabeller for klassene dine (for å støtte refleksjon eller RTTI)
Trinn 11. Skriv utføreren eller kodegeneratoren som vil binde alt sammen
Trinn 12. Skriv mange testprogrammer for å teste språket
Du vil lage programmer som understreker byrdene ved din formelle grammatikk for å se at kompilatoren godtar alt som er inne i definisjonen din og avviser alt som er utenfor den
Trinn 13. Vurder hvordan brukeren vil feilsøke sine egne programmer
Trinn 14. Hvis språket ditt bruker et standardbibliotek, vil du skrive det
Sammen med en søppelsamler eller andre kjøretidsfunksjoner hvis du trenger det.
Spesielt, hvis du skriver en kompilator, trenger du koden som operativsystemet vil utføre for å begynne å kjøre brukerkoden (for eksempel tildeling av alle globale variabler)
Trinn 15. Publiser språket ditt, sammen med spesifikasjonen for det og noen eksempler på hva du kan gjøre i det
Ikke glem å dokumentere hvordan du kan integrere med eksisterende biblioteker, språk og hvordan du bruker kjøretidsfunksjonene og/eller standardbiblioteket
Video - Ved å bruke denne tjenesten kan noe informasjon bli delt med YouTube
Tips
- Start med å designe språket ditt, og ikke skriv noen kode før du er fornøyd og har svart på alle (eller de fleste) spørsmålene eller problemene knyttet til designet ditt, siden det er lettere å endre designet tidligere enn senere.
- Kjenn målplattformen din (operativsystem og biblioteker) for kompilatoren/tolken din. Tross alt skal du bruke den og manipulere den.
Advarsler
- Tenk om du virkelig trenger et nytt språk, og hva språket ditt har av nytt som andre språk ikke har (Det kan være en kombinasjon av funksjoner eller en enkelt funksjon).
- Å skrive språk er vanskelig hvis du ikke vet hva du gjør. Det krever mye øvelse også.
- Forbered deg på å bruke litt tid på språkdesign, siden du ikke har mulighet til å endre språk når du har skrevet kompilatoren og forbi designpunktet.
- Ikke prøv å basere funksjonene dine i en forening av flere språk, som å si at språket ditt vil være en forening av språk X, språk Y og språk Z. Historien har vist oss at språk som er opprettet på en slik måte aldri vil lykkes, eller alle ville programmere PL/1 i stedet for noe basert på C.