a few issues/annoyances

[vpisarev]

... found during conversion of the compiler to ficus:

• <some variant constructor>(_) pattern should work for any number of formal parameters.
• when match case (or maybe any block) finishes with declaration or consists of just one declaration, there is very strange diagnostic
• also there is strange diagnostic when '::' is used with lists of unproper type
• 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)
• comparison with empty list should be fast
• comparison of variant value/variable with parameter-less variant case should be fast (just tag comparison)
• 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)
• KForm.init_all() was found, but it belongs to Ast module! After type checking the module environment needs to be cleaned.
• 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
• formatting of the output .c code is generally fine, though a bit ugly in some places. Need to polish it.