updates

[ocean-D] / Ocean-functions

diff --git a/Ocean-functions b/Ocean-functions
index 9014d1adc9b26d9d057c3d6d9361046db713acc8..50834001635905cb15e345b353f972f39ea1f280 100644 (file)
--- a/Ocean-functions
+++ b/Ocean-functions
@@ -1,8 +1,9 @@
-I want to add functions and procedures soon.  I should decide on syntax at least.
+I want to add functions and procedures soon.  I should decide on syntax
+at least.
 
-The args to a function are effective a struct, so I want it to look the same.
-C doesn't allow "int a, b, c" in the parameters, which I think is clumsy.
-struct can be
+The args to a function are effectively a struct, so I want it to look
+the same.  C doesn't allow "int a, b, c" in the parameters, which I
+think is clumsy.  struct can be
 
   struct name:
      a,b,c:number
@@ -13,7 +14,7 @@ So function might be
    func name:
        arg1, arg2: type
        arg3: type2
-   returns type
+   return type
    do:
        stuff
 
@@ -22,16 +23,82 @@ it has a return structure.  So many C functions have 'ret' or 'result'
 variable that it might be nice to follow the Pascal approach of
 assigning to the function name??  or having
 
-    func name:
+    func name
        args:types
-    returns:
+    return
        results:types
-    do:
+    do
        statements
 
 A shorter version would be
 
     func name(args:types;args:types):type { }
 or
-    proc name(args:types;args:types):(result:type;...) {}
+    func name(args:types;args:types):(result:type;...) {}
 
+
+Can arguments be optional?
+ - yes, if "= value" follows the type
+Can we have variable number of args
+ - yes. Any arg can be an inline-array. The last arg can
+   have undefined length [].
+Can named args be passed in
+ - yes, once I have a syntax for manifest structs
+   
+Arrays seem very different from structs.
+ - they don't have names (as types)
+ - they don't need grouping in function params??
+Does this make any sense?
+Maybe I should require the grouping
+  printf("%d %d %d", (1,2,3))
+??
+
+
+Functions can be used before being declared - analysis happens after all is read.
+
+'main' is given an array of strings of unknown length.
+So I need the formal parameter to accept variable-length arrays.
+Do I use
+   argv:[] string
+and support "argv.len", or do I use
+   argv:[argc] string
+which instantiates argc with the length?
+Probably the latter.
+
+Arrays have to be passed by reference, they are const if :: used for type.
+Structs .. ditto.
+Strings and numbers are immutable.
+
+So I need functions to turn strings into number or bool.
+Just bool() and number() for now.
+So
+DONE 1/ change 'program' to make everything a string, and use functions to get numbers.
+DONE 2/ change 'program' to receive an array with bindably size
+DONE 3/ change 'program' to 'func main' etc
+DONE4/ allow more functions.
+
+What syntax to use for formal types?
+I will need type parameterisation some day.  For now I just need the
+size of an array to be parameterised.
+  argv:[argc]string
+looks like normal type.  But it isn't clear if argc is a global constant
+or a variable.
+  argv:[argc:int]string
+seem redunant because of course the array index is an int.
+  argv:[argc:]string
+might be acceptable.
+It is like leaving out the type is
+   a := 4
+
+So let's go with that.
+
+
+DONE To handle functions, and recursion in particular, I need a concept of a
+stack frame in the interpreter.  This needs to include room for
+parameters and results and local variables.  So a function needs to know
+the size of its frame, and each variable needs an offset.
+So I need to switch 'program' over to this approach before adding
+functions.
+Then the function frame will have a results frame separate from the
+main frame, as it can last longer.  So each variable needs to be marked
+as 'result' or not.