Update README, bump version

notes.txt

@@ -43,11 +43,24 @@ Reserved symbols that are still not used as a line type: `^+-=</[]*{}|\_!?.,;)"&
 
 Broad goals and ideas that may never be implemented. Mostly used as personal post-it notes.
 
-TODO: type system is not super nice to use
+TODO: support parametric types in contraints: list(number)
+     should then also allow polymorphic constraint like
+     $ fn(l::list('a), x::'a)
+          (push a constraint context when checking compatibility)
+     or more generic constraints? allow custom functions to check constraints, etc (performance?)
 
-TODO: distinguish between list and argument list to confuse less pairs with named arguments
+TODO: a way to alias key names in pairs/maps? the alias should not end up in the save file... we could use variable for that, like
 
-TODO: some sensible way to capture text event in string litterals (string interpolation)? -> meh, this means we can capture choice events, and choice events contain their code block, and we don't want to store code blocks in the save file (as code can be updated/translated/whatever)
+     :foo:bar = "key"
+     :map = {bar=42}
+
+     i.e. just remove the special case of interpreting identifiers as strings in pairs. But then might need to distinguish from the named argument syntax in function calls.
+
+TODO: type system is not super nice to use.
+     UPDATE: tried to implement a static type system, ain't worth it. Would require major refactoring to go full static with good type inference. The language is supposed to allow to not have to worry about low level stuff, so no deal if the type inference isn't good. Thank you multiple dispatch for making everything complicated (i still love you though)... Well, if I ever reimplement Anselme, let's thank the Julia devs for doing the hard work: https://docs.julialang.org/en/v1/devdocs/inference/
+
+TODO: some sensible way to capture text event in string litterals (string interpolation/subtexts)? -> meh, this means we can capture choice events, and choice events contain their code block, and we don't want to store code blocks in the save file (as code can be updated/translated/whatever)
+     ignoring choice events, we might be able to use subtexts in string litterals; using the same code for text lines and text litterals? we would lose tags...
 
 TODO: the function decorator feels a bit glued-on to the current syntax
 
@@ -65,7 +78,7 @@ TODO: fn/checkpoint/tag: maybe consider them a regular func call that takes chil
      :a = $(args)
      	stuff
 
-     how are children passed on? overloading?
+     how are children passed on? overloading? -> means a code block would be passed as a value, how to avoid it ending up in the save file?
 
      if not possible, at least make checkpoint or fn defined using the other or some superset... -> checkpoints defined using fn
 
@@ -83,18 +96,18 @@ TODO: fn/checkpoint/tag: maybe consider them a regular func call that takes chil
 TODO: perform seen/reached/etc default variable not in interpreter but using parse-time macro
 
 TODO: no function call without () (reference to fn instead?). Fn could be stored in save but replaced with new versions on code reload... -> how to track these references?
-                      if we make fn first class this means anonymous fn, is it ok?
+     if we make fn first class this means anonymous fn, is it ok? -> no way to track anonymous fn, so no.
 
 TODO: make language simple enough to be able to reimplement it in, say, nim. Especially the AST interpreter (we could precompile a lot of stuff...)
 
-TODO: test reacheability of script paths
+TODO: test reacheability of script paths + visualization of different branches the script can take. For one of those overarching story visualization thingy.
 
 TODO: redisign the checkpoint system to work better when used with parallel scripts (if both change the same variable, will be overwritten); not sure how to do that, would need some complicated conflict resolution code or something like CRDT...
 
 TODO: redisign a static type checking system
 If we want to go full gradual typing, it would help to:
-* add type anotation+type check to variables (:a::number=5) and functions return ($ f()::number)
-* enforce some restrictions on type (assume they're constant?)
+* add type anotation+type check to functions return ($ f()::number) -> there's a lot of function calls, so probably checked at compiling only
+* enforce some restrictions on type (assume they're constant/sublanguage, not full expressions)
 * make some tuple/list distinction (homogenous/heterogenous types) as right now index operations are a type roulette. Or type annotate lists using some parametric type.
 Advantages:
 * can be used for better static variant selection; if everything is type annotated, selection could be restricted to a single function