ontwerpbesluiten.txt

   1 -- Types zonder arity
   2 We gebruiken types zonder arity (Int -> Int -> Void) ipv (Int Int -> Void)
   3 Waarom?
   4 Mooiere puurdere lambda-calculus. Is chill straks met hogere orde functies (denken we)
   5 Staat mooie shizzle zoals in Haskell toe (f :: a -> a, g :: a -> a, f = g)
   6 Simpeler om te parsen
   7 Con: wellicht kut met code generatie, wie weet.
   8
   9 ---
  10 Functies en variabelen delen 1 namespace.
  11 Dat is met het oog op hogere orde functies, dan kan een parameter voor een functie een andere
  12 functie zijn, of een variabele en als die 2 aparte namespaces hebben is dat moeilijk onduidelijk /
  13 praktisch onmogelijke met type inteference
  14
  15
  16 ---
  17 Functies kunnen voor correct typechecken alleen functies gebruiken die DAARNA
  18 gedefinieerd zijn
  19
  20 —
  21
  22 Globaal gedefinieerde dingen worden als constanten beschouwd. Enkel in functies gedefinieerde vars zijn mutable. Twee redenen: 1 we behouden onze programmeurs voor het gebruik van globale state, want dat is de wortel van het kwaad. Daarnaast past het goed bij dat _alles_ op top level een functie is. Als je zegt i = next x; en x wijzigt tussendoor en je checkt dan weer i dan wordt i opnieuw geevalueerd en dat levert dan dus een andere waarde op, en dat wil je niet.
  23
  24
  25 — mbt code generation
  26 —-
  27 Bij callen is de callee verantwoordelijk voor het opslaan van de registers, indien nodig. Dit omdat _alles_ als function wordt gecalled, dus ook: i=4; b=i+1; levert een functiecall naar i op in de toewijzing van b.