todo

* Update REPL words on erasure of definitions or user-types

* Implement typical Bitcoin scenarios

1. Оплата на хеш от адреса
2. Оплата на хеш от скрипта, 1 и 2 могут быть одинаковые, но мне интересен тонкий момент, что в битке для 2 нужен redeem script, который надо отдельно хранить.
3. Транзакция траты K from N мультисига
4. Hash lock
5. Time lock
К этим всем транзам надо проверить, что их id не меняется после подписи соответствующих выходов каждой из сторон, чтобы можно было делать цепочки неопубликованных транзакций.

* debug pattern-matching compiler, for now switched to tuple-based compiler
   but it should not remain in the long run.

* consider compilation of arguments
   It's desirable to keep a map from text keys to primitives.
  But how can we implement it in the low-level language?
  Should we create associative lists for each primitive values.
  Then instead of polymorphic getArg we would have getIntArg, getTextArg, etc
  Also we can simplify it by reducing text to value map to list of values.
  It would be easier implement right now. And this is how it works in the Ergo.

* add elimination of polymorphic functions.
   Do it on the level of extended LC.

* implement let-pattenrs for repl in the style of
    
    (a, b) = getPair

* prohibit recursive type definitions

* pattern matching compiler reorders constructors in alphabetical order.
   In many cases it can lead to counter intuitive errors in pattern matching.
   Consider fix order reaarangement. Pattern compiler should keep original order
  of constructors. Case where problem is highlighted:

  Here We have pattern with constructor Bob it goes last but due to alphabetical order
  it goes first and the whole expression becomes Name -> Bool instead of more intuitive Color -> Bool

data Color
  = Red
  | Green
  | Blue

data Name = John | Bob | Wanessa

xorCol Red     = True
xorCol Wanessa = True
xorCol Green   = True
xorCol Bob     = False

* consider name collisions of fresh vars within user module loading stage

* consider name collision of fresh vars inside AlgorithmW
   make dedicated separate constructor for FreshVars
  parametrise everything by type of Var-name

* big number of tuples-constructors user types - type-checkers blows up

* make modules, imports (build from several source files)

* check performance (intensive task)

* refactor for separation of reduction of syntax-sugar and execution
   make small separate subset language on which we execute (extended lambda-calculus)

* optimize lambda-reductions

* docs-update