Analyse

Scopes (let/local)

• Mulighed: Behold scopes.
• Fordel: JS har scopes så det er muligvis unødvendigt ekstra arbejde at ophøje alt.
• Mulighed: Ophøj alt til globalt niveau.
• Fordel: Koden til dette findes allerede fra den oprindelige oversætter.

Repræsentation af funktioner

• Problem: En anonym funktion i ML kan assignes til en val og bruges efterfølgende
• Problem: En funktion kan defineres ud fra en anden funktion hvor nogle argumenter er givet (curried functions)
• Mulighed: Repræsentation af anonyme funktioner kan gøres direkte i JS.

Håndtering af rekursive funktioner

• Mulighed: Brug rekursive JS-funktioner
• Fordel: Direkte oversættelse
• Ulempe: Kan være uoptimeret/tungt i JS (dette skal undersøges og er pt en spekulation)
• Mulighed: Brug løkker
• Fordel: Kan være meget effektivt
• Ulempe: Mere kompliceret løsning
• Mulighed: Brug en trampolinfunktion
• Ulempe: Giver et konstant overhead som gør mindre rekursioner tungere end nødvendigt
• Fordel: Umiddelbart simpel løsning.

Repræsentation af atomer, datatyper (internt, på ML-siden i bagenden)

• Mulighed: repæsentér alle atomer som strenge
• Fordel: vi kan bruge TextIO direkte, da alt i sidste skal være strenge og hvis de skal være strenge på JS-siden skal der alligevel indsættes "..." omkring. Derudover har typetjekket fundet sted. Chars skal alligevel håndteres som strenge på JS-siden. Giver mulighed for en simplere abstrakt JS-syntaks.
• Mulighed: Bibehold typerne så langt ind i oversætteren som muligt og først konvertere til strenge ved output til JS-fil.
• Fordel: når typerne bibeholdes undgås det at blande dem.
• Ulempe: Den abstrakte JS-syntaks skal være mere kompleks end ovenstående.

Repræsentation af atomer, datatyper (eksternt, på JS-siden)

• Udfordring: Overflow på heltal.
• Udfordring: Words, unsigned (JS har funktionen ParseInt(string, 16)). Kan være større end ML heltal da den er unsigned. Hexadecimal ser en smule forskelligt ud på ML ift. JS.
• Udfordring: Datatyper bliver i Lambda-sproget lavet om til lister (BLOCK med et tag på 3 og span er antallet af elementer). Typetjekket er foretaget og vi skal derfor ikke håndtere datatypen som andet end en liste i JS.

Lister (lister, tupler, records)

• JS lader kun til at håndtere dynamiske lister kaldet arrays.

• Fremtidige versioner giver muligvis mulighed for lister af fast længde, hvilket kunne bruges til tuples og records.

• en mulighed til tupler pt er at bruge lister med et form for længdetjek; enten på ML-siden eller på JS-siden som et bibliotek.

• Dicts giver ikke nogen fordele da disse kan udvides fuldstændig som lister

• Alternativt skal begrænsingen ignoreres og antage at det bliver overholdt fra Moscow ML's side og at evt. udefrakommende indgreb (user input o.lign.) også overholder

• Et problem ved ikke at håndtere afgrænsing af tupler (i.e. ved lister på JS-siden) er at eksterne moduler/funktioner/programmer kan tilgå/kalde de ML-JS oversatte funktioner med en liste der er længere end den originale tuples længde. Hvis tupler på JS-siden håndteres med løkker der arbejder på alle elementer i listen risikeres det at den ødelægger korrektheden, eftersom den kan arbejde på vilkårligt mange elementer.

• Med ML's typetjek kan ovenstående ikke ske internt og ved kun at tilgå tupler via indeks og ikke løkker kompromitteres korrektheden ikke.

• Records er en generaliseret form af tupler, hvorfor de kan håndteres på samme måde.

Moduler og linking i mellem disse, og structs

• Mulighed: Læg alle moduler i en stor JS-fil, hvor en liste af allerede åbne moduler vedligeholdes, så det samme modul ikke åbnes flere gange.
• Problem: Alt skal rekompileres ved en ændring i blot et enkelt modul.
• Problem: Scopes bliver et problem hvis alle ikke er globalt.
• Mulighed: Hver SML-fil tilsvarer en JS-fil som f.eks. i HTML kan linkes med en src=....
• Problem: Forskellige miljøer skal håndteres forskelligt. F.eks. Node.js og HTML/Web.

Design af abstrakt JS-syntaks (og om denne overhovedet skal være der)

• Mulighed: Opdelt i simplere skridt mellem Lamda->JS abstrakt->JS. Semantikken oversættes til det abstrakte JS som umiddelbart direkte kan oversættes til JS med fokus på syntaks.
• Problem: Definition af nyt abstrakt sprog er ikke-trivielt.
• Mulighed: Direkte oversættelse mellem Lambda og JS.
• Problem: Hvert skridt kan hurtigt blive væsentligt større og komplekst. Her skal både tages højde semantik og syntaks.
• Mulighed: Direkte oversættelse mellem Moscow ML og JS. er dette Relevant?