... found during conversion of the compiler to ficus:
[x] <some variant constructor>(_) pattern should work for any number of formal parameters.
[x] when match case (or maybe any block) finishes with declaration or consists of just one declaration, there is very strange diagnostic
[x] also there is strange diagnostic when '::' is used with lists of unproper type
[x] ocaml2fx tool should handle if's without then-branches or without else-branches in more intelligent way to reduce further refactoring
[ ] walk_kexp, KMkArray() case (with nested list comprehensions initially) required some workaround to compile (wrong C code is generated)
[x] comparison with empty list should be fast
[x] comparison of variant value/variable with parameter-less variant case should be fast (just tag comparison)
[x] when inside a recursive function that uses free variables (i.e. needs a closure), e.g. typ2ktyp in KNormalize.fx we pass this function itself into some generic function, e.g. List.map, we cannot pass its standard function structure (FP), because it's created after the function declaration. 2 solutions: 1) create another function structure with the input fx_fv (do not forget to increment the reference counter before the call and decrement it after), 2) create the standard closure earlier (may not always work)
[x] KForm.init_all() was found, but it belongs to Ast module! After type checking the module environment needs to be cleaned.
[x] would be nice to extend 'fold' syntax to set initial values separately, not via tuple packing/unpacking
[ ] sometimes variable tuple arguments (...) do not work properly, see for example the commented off tuple hash() function in Builtins.fx
[ ] the generated .c code shows some instabilities after even very minor changes. For example, for some modules of the compiler a slightly different .c code is generated even though they are not edited themselves. So far the only observed instabilities are about the ordering of locally defined variables, which is a not big problem and we cannot say that compiler shows non-deterministic behavior, but it's still an issue
[x] formatting of the output .c code is generally fine, though a bit ugly in some places. Need to polish it.
... found during conversion of the compiler to ficus:
<some variant constructor>(_)pattern should work for any number of formal parameters.