diff --git a/lambdas.kl b/lambdas.kl
index 29af688..81920d6 100644
--- a/lambdas.kl
+++ b/lambdas.kl
@@ -1,4 +1,3 @@
-
 a_type :: int
 pointer_type :: *int
 null_pointer: pointer_type = null
@@ -15,17 +14,12 @@ if_stmt :: (cond: int): type
 
 
 add_10 :: (size: int): int
-  // @todo: before the generation c pass, each stage should have it's own
-  //        tree transformation phase, where it yanks functions out etc.
   add_20 :: (new_size: int): int
     return 20
 
   add :: (a: int, b: int = 10): int
     return a + b
 
-  // thing_2 :: (a: int = "String")
-    // return
-
   constant :: 20; result := constant + 10
 
   v3 := add(1,2)
diff --git a/main.cpp b/main.cpp
index 876c524..e1df43c 100644
--- a/main.cpp
+++ b/main.cpp
@@ -6,49 +6,58 @@
 #include "typechecking.cpp"
 #include "ccodegen.cpp"
 
-// 2022.05.28 - On lambda expressions
-// I think it's not wise to add the multiline lambda expressions
-// As is the case with python it would require new alternative syntax.
-// The idea was to imply that the whitespace significant syntax is just
-// inserting '{' '}' ';' automatically and if you decide to write a brace
-// it stops being whitespace significant and you can type everything with semicolons and braces
-// Problem is first of all it's kind of weird to have a completly different syntax
-// in a language to solve something that is a minor inconvenience,
-// second of all it turned out to be kind of bad, maybe if it would be more
-// complicated then it would be ok but it implies that you have to semicolon end
-// a lot of thing unintuitively.
+/*
+2022.05.28 - On lambda expressions
+I think it's not wise to add the multiline lambda expressions
+As is the case with python it would require new alternative syntax.
+The idea was to imply that the whitespace significant syntax is just
+inserting '{' '}' ';' automatically and if you decide to write a brace
+it stops being whitespace significant and you can type everything with semicolons and braces
+Problem is first of all it's kind of weird to have a completly different syntax
+in a language to solve something that is a minor inconvenience,
+second of all it turned out to be kind of bad, maybe if it would be more
+complicated then it would be ok but it implies that you have to semicolon end
+a lot of thing unintuitively.
 //
-// Probably single line lambdas should be ok. Currently braces turn off indentation
-// awareness. There might be something you can do by trying to turn that on
-// problem is that complicates parsing a lot cause you have to account for multiple
-// indent styles, which means error messages become bad.
+Probably single line lambdas should be ok. Currently braces turn off indentation
+awareness. There might be something you can do by trying to turn that on
+problem is that complicates parsing a lot cause you have to account for multiple
+indent styles, which means error messages become bad.
 
-// 2022.05.30 - On constructors and compound expressions
-// I unified the compound expression syntax (Type){} with function call syntax Type().
-// It's differentiating on whether you used type. I think there is a benefit to the language
-// not having an idea of overloading the type constructor. You will always know what will happen.
-// Unlike C++ for example. It seems like a minefield that can fuck your mind up. So many corner cases
-// and variants. having the idea of compounds doing one thing is reassuring I think.
-// You can always do a constructor by writing a function with lower case type if you want that.
-// For now I don't thing it should be overloadable.
-//
+2022.05.30 - On constructors and compound expressions
+I unified the compound expression syntax (Type){} with function call syntax Type().
+It's differentiating on whether you used type. I think there is a benefit to the language
+not having an idea of overloading the type constructor. You will always know what will happen.
+Unlike C++ for example. It seems like a minefield that can fuck your mind up. So many corner cases
+and variants. having the idea of compounds doing one thing is reassuring I think.
+You can always do a constructor by writing a function with lower case type if you want that.
+For now I don't thing it should be overloadable.
 
-/// @todo
-/// [x] - Typespecs should probably be expressions so stuff like would be possible :: *[32]int
-/// [x] - Initial order independence algorithm
-/// [ ] - Cleanup the mess with constant bindings
-/// [x] - Struct calls
-/// [x] - Default values in calls
-/// [x] - Resolving calls with default values
-/// [x] - Resolving calls with named args, with indexed args
-/// [x] - Structs
-/// [ ] - Default values in structs???
-/// [ ] - Enums
-/// [ ] - For loop
-/// [ ] - Switch
-/// [ ] - Think about compound expressions, unify with calls - maybe Thing(a=1) instead of Thing{a=1}
-/// [ ] - Lexer: Need to insert scope endings when hitting End of file
-/// [ ] - Add single line lambda expressions/
+
+@todo
+[ ] - Enums
+[ ] - Enum . access to values
+[ ] - Fixing access to constants, in C we cant have constants inside of structs / functions so we need to rewrite the tree
+[ ] - Access through struct names to constants Arena.CONSTANT
+[ ] - Default values in structs??? Should compound stmts bring values from default values?? Maybe not? Whats the alternative
+[ ] - For loop
+[ ] - Switch
+[ ] - Lexer: Need to insert scope endings when hitting End of file
+[ ] - Add single line lambda expressions
+
+@donzo
+[x] - Struct calls
+[x] - Default values in calls
+[x] - Resolving calls with default values
+[x] - Resolving calls with named args, with indexed args
+[x] - Structs
+[x] - Struct field access
+[x] - Struct field access with dots while compiling to arrows in c
+[x] - Typespecs should probably be expressions so stuff like would be possible :: *[32]int
+[x] - Initial order independence algorithm
+[x] - Think about compound expressions, unify with calls - maybe Thing(a=1) instead of Thing{a=1}
+
+*/
 
 
 int main(){
diff --git a/order2.kl b/order2.kl
index e8b1691..9ff8c1b 100644
--- a/order2.kl
+++ b/order2.kl
@@ -1,5 +1,4 @@
 Str16 :: String16
-
 arena_pointer: *Arena = null
 thing: Arena
 no_type := thing
@@ -19,11 +18,11 @@ Arena :: struct
   len : int
   cap : int
 
-  constant_inside :: 10000
-constant_outside :: 10000
+  get_len :: (s: *Arena): int
+    return s.next.len
 
-get_len :: (s: *Arena): int
-  return s.next.constant_inside
+
+  constant_inside :: 10000
 
 
 string16: Str16