Update README.md

README.md

@@ -110,6 +110,20 @@ end
 
 If no type is specified then then type will be dynamic - exactly what the Lua default is.
 
+When a typed function is called the inputs and return value can be validated. Consider the function below:
+
+```
+local function foo(a, b: int, c: string)
+  return
+end
+```
+When this function is called the compiler can validate that `b` is an int and `c` is a string. `a` on the other hand is dynamic so will behave as regular Lua value. The compiler can also ensure that the types of `b` and `c` are respected within the function. 
+
+Return statements in typed functions can also be validated.
+
+Array Types
+-----------
+
 When it comes to complex types such as arrays, tables and functions, at this point in time, I think that Ravi only needs to support explicit specialization for arrays of integers and doubles. 
 
 ```
@@ -122,16 +136,19 @@ function foo(p1: {}, p2: int[])
 end
 ```
 
-When a typed function is called the inputs and return value can be validated. Consider the function below:
+To support array types we need a mix of runtime and compile time type checking. The Lua table type will be enhanced to have type information so that when an array type is created the type of the array will be recorded. This will allow the runtime to detect incorrect usage of array type and raise errors if necessary. However, on the other hand, it will be possible to pass the array type to an existing Lua function as a regular table - and as long as the Lua function does not attempt to subvert the array type it should work as normal.
 
-```
-local function foo(a, b: int, c: string)
-  return
-end
-```
-When this function is called the compiler can validate that `b` is an int and `c` is a string. `a` on the other hand is dynamic so will behave as regular Lua value. The compiler can also ensure that the types of `b` and `c` are respected within the function. 
+The array types will have some special behaviour:
 
-Return statements in typed functions can also be validated.
+* indices may not be negative
+* array will grow automatically if user sets the element just past the array length
+* it will be an error to attempt to set an element that is beyond len+1 
+* the current used length of the array will be recorded and returned by len operations
+* the array will only permit the right type of value to be assigned (this will be checked at runtime to allow full compatibility with Lua)
+* accessing out of bounds elements will cause an error, except for setting the len+1 element
+* it will be possible to pass arrays to functions and return arrays from functions - the array types will be checked at runtime
+* it should be possible to store an array type in a table - however any operations on array type can only be optimised to special bytecode if the array type is a local variable. Otherwise regular table access will be used subject to runtime checks.
+* array types may not have meta methods - this will be enforced at runtime
 
 All type checks are at runtime
 ------------------------------