Update README.md

Dibyendu Majumdar 9 years ago
parent f5f94b0515
commit 5b6b978eb4

@ -70,14 +70,28 @@ Same as Lua.
Language Syntax
---------------
I hope to enhance the language to enable static typing of following:
I hope to enhance the language to variables to be optionally decorated with types. As the reason for doing so is performance primarily - not all types benefit from this capability. In fact it is quite hard to extend this to generic recusrive structures such as tables without encurring signficant overhead. For instance - even to represent a recusrive type in the parser will require dynamic memory allocation and add great overhead to the parser.
So as of now the only types that seem worth specializing are:
* int (64-bit)
* double
* array of ints
* array of doubles
Everything else will just be dynamic type as in Lua. However we can recognise following types to make the langauge more user friendly:
* string
* table
* array (this will be an optimisation of the array usage of a table)
* bool
* functions and closures
* function
* nil
* boolean
And we may end up allowing additionally following types depending on whether they help our goals:
* array of booleans
* array of strings
* array of functions
The syntax for introducing the type will probably be as below:
```
@ -96,30 +110,16 @@ end
If no type is specified then then type will be dynamic - exactly what the Lua default is.
Tables and arrays need special syntax to denote the element / key types. The syntax might use the angle brackets similar to C++ template aruguments.
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.
```
function foo()
local t1 = {} -- table<any,any>
local t2 : table<string,string> = {} -- table with string keys and values
local t3 : table<string,double> = {} -- table with string keys and double values
local a1 : array<int> = {} -- array of integers
function foo(p1: {}, p2: int[])
-- p1 is a table
-- p2 is an array of integers
local t1 = {} -- t1 is a table
local a1 : int[] = {} -- a1 is an array of integers, specialization of table
local d1 : double[] = {} -- d1 is an array of doubles, specialization of table
end
-- array of functions
local func_table : array<function> = {
function (s: string) : string
return s
end,
function (i, j)
return i+j
end
}
```
An alternative syntax for array and table declarations I am considering:
```
local a1 : int[] = {} -- array of integers
local t1 : double[int] = {} -- table keyed by integers containing double values
```
When a typed function is called the inputs and return value can be validated. Consider the function below:
@ -133,9 +133,9 @@ When this function is called the compiler can validate that `b` is an int and `c
Return statements in typed functions can also be validated.
Mixture of compile time and runtime checks
------------------------------------------
To keep with Lua's dynamic nature I plan a mix of static type checking and runtime type checks. Runtime type checks may be used for example when a function is called or values from a function call are saved into variables. Also on entry into functions the parameters may be subject to runtime checks.
All type checks are at runtime
------------------------------
To keep with Lua's dynamic nature I plan a mix of compile type checking and runtime type checks. However due to the dynamic nature of Lua, compilation happens at runtime anyway so effectually all checks are at runtime.
Implementation Strategy
-----------------------

Loading…
Cancel
Save