<commit_before>KNOWN BUGS:
List and hash types are still included in their specialization list even if GC:ed.

LANGUAGE FEATURES:
Default function argumet values. These also need to be part of the function interface and contained in function keys.
Named arguments for function calls.
Map construction syntax.
Implement autowrapping of methods
Implement node type: Const (Is this needed?)
Implement node type: Type specializations (Is this needed?)
User defined properties
User defined variadic functions
User defined templates with full specialization support
Inheritance
True type intersections
Continuations
milter/fap
Make all types inherit from Object
Int should just be an interface,with two backing implementations

STDLIB FEATURES:
HTML documentation extractor
The rest of the hashtable functions (filter, contains, properties for keys and values, etc)
Set type
String format function
File type
toString methods for Hash, List, Range, Function, Node, etc

IDEAS:
Invertigate if we can completely drop the stack_template struct and just use types for that purpose

RELIABILITY:
Validate that all functions end with an empty stack frame
Tests for namespaces
Tests for nested macro members
Tests for integer math
Tests for floating point math
Tests for HashMap
Tests for type checking on invalid specialization
Test return types of complex expression types, e.g. if(){}+1.

DOCUMENTATION:
Document all vm ops w.r.t. manipulating the stack, etc.

PERFORMANCE:
Performance target: It should be possible to do the mandelbrot calculation in 0.05 seconds.
Implement tail recursion
Avoid creating trampolines when possible
Perform escape analysis on stack frames and allocate ones who are never referenced in non-GC:ed memory.
Inlining of if/while bodies into main method
Make a verion of the fold op that takes a parameter

Figure out how to handle the map function. We can't make a prototype
function, we actually want the type hinting to go in the other
direction; the return value of the function supplied to map should determine the
return type of the function. I guess we want some kind of magical
syntax for annotating a method that will make the return type depend
on the input type? Or can we simply use a clever macro? A template?

Map construction syntax<commit_msg>Todo list update<commit_after>KNOWN BUGS:
List and hash types are still included in their specialization list even if GC:ed.

LANGUAGE FEATURES:
Default function argumet values. These also need to be part of the function interface and contained in function keys.
Named arguments for function calls.
Map construction syntax.
Implement autowrapping of methods
Implement node type: Const (Is this needed?)
Implement node type: Type specializations (Is this needed?)
User defined properties
User defined variadic functions
User defined templates with full specialization support
Inheritance
True type intersections
Continuations
milter/fap
Make all types inherit from Object
Int should just be an interface,with two backing implementations

STDLIB FEATURES:
HTML documentation extractor
The rest of the hashtable functions (filter, contains, properties for keys and values, etc)
Set type
String format function
File type
toString methods for Hash, List, Range, Function, Node, etc

IDEAS:
Invertigate if we can completely drop the stack_template struct and just use types for that purpose

RELIABILITY:
Validate that all functions end with an empty stack frame
Tests for namespaces
Tests for nested macro members
Tests for integer math
Tests for floating point math
Tests for HashMap
Tests for type checking on invalid specialization
Test return types of complex expression types, e.g. if(){}+1.

DOCUMENTATION:
Document all vm ops w.r.t. manipulating the stack, etc.

PERFORMANCE:
Performance target: It should be possible to do the mandelbrot calculation in 0.05 seconds.
Bytecode optimization: Different getters for static and non-static members to up performance a bit. Also consider doing something about properties, performance-wise. Gprof indicates that member access is a significant performance bottleneck.
Implement tail recursion
Avoid creating trampolines when possible
Perform escape analysis on stack frames and allocate ones who are never referenced in non-GC:ed memory.
Inlining of if/while bodies into main method
Make a verion of the fold op that takes a parameter

Figure out how to handle the map function. We can't make a prototype
function, we actually want the type hinting to go in the other
direction; the return value of the function supplied to map should determine the
return type of the function. I guess we want some kind of magical
syntax for annotating a method that will make the return type depend
on the input type? Or can we simply use a clever macro? A template?

Map construction syntax
{'fraction_non_alphanumeric': 0.02857142857142857, 'fraction_numerical': 0.0016684045881126173, 'mean_word_length': 5.125159642401021, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3760295', 'n_tokens_mistral': 1148, 'n_tokens_neox': 1114, 'n_words': 722}