Type inference prototype based on static analysis

CMakeLists.txt

@@ -89,7 +89,9 @@ add_library(stapi
     src/ParsedBlock.cpp
 
     src/ControlGraph.cpp
+    src/TauLinker.cpp
     src/ControlGraphVisualizer.cpp
+    src/TypeAnalyzer.cpp
 )
 
 set(MM_CPP_FILES

doc/types.txt

@@ -17,7 +17,7 @@
     id: param
         ^param
 
-Ти́повое выражение:
+Т́иповое выражение:
     self::*, param::* -> self, param
 
 
@@ -26,13 +26,13 @@
         ^ a + b
 
 Контекст object sum: intvara and: intvarb
-    self::*, (SmallInt), (SmallInt) -> self, (SmallInt)
+    self::*, a::(SmallInt), b::(SmallInt) -> self', (SmallInt)
 
 Контекст object sum: 2 and: 3
     self::*, a::2, b::3 -> self, 5
 
 Обобщенный метод
-    self::*, a::*, b::* -> self'::*, *
+    self::*, a::*, b::* -> self', *
 
 то есть, литеральные значения протаскиваются прямо через тип
 
@@ -72,9 +72,10 @@
 Контекст object dirty: 42
     self::[_,_,_], param::42 -> self'::[_,_,42], 43
 
+Примечание: в случае утекания self, мы не можем утверждать, что self' будет таким. Придется фолбечиться на self'::*
 
 
-А теперь самый вынос мозга — система контекста виртуальной машине — это монод в категории эндофункторов! Монада то бишь.
+А теперь самый вынос мозга — система контекста виртуальной машине — это моноид в категории эндофункторов! Монада то бишь.
 Переход виртуальной машины от одного состояния к другому — это монадическая операция.
 
 А это внезапно означает:
@@ -106,6 +107,7 @@
 Монадические отношения в связи с объектом self позволяют формализовать тот факт, что при вызове метода поля самого объекта не меняются.
 Это позволяет более смело выполнять оптимизации и связывать далекие участки графа без опасения что типы совпали «случайно».
 
+Поправка — нихрена :( Если self утек в другой объект, то вызывая методы он может поменять и нас. Только при инлайнинге и доказательсве.
 
 
 Типы методов:
@@ -184,3 +186,90 @@
 Впрочем, ветви кэша кодируются как вызовы специализированных версий методов,
 поскольку в пределах ветви класс отправителя (self) становится известен.
 
+
+Блоки, акт второй.
+
+Классификация блоков относительно типов
+    ContextFree         [ 42 ], [ :x | x + 1 ], [ :x :y | x < y ]
+    ContextAccessor     [ x message ], [ x + 1 ], [ anArgument message: aTemporary ]
+    ContextMutator      [ x <- nil ], [ :x | sum <- sum + x ]
+
+    BlockReturn         [ ^42 ]
+
+Классификация точки вызова блоков
+    Never
+    Once                y <- [ :x | x ] value: 42
+    Maybe               <Never + Once>
+    Multi               1 to: 10 do: [ :x | sum <- sum + x ]
+    Escape              *::anObject take: (Block)::aBlock
+
+
+В зависимости от вида блока и точки его вызова, вывод типов может быть реализован по-разному.
+
+В наиболее общем случае необходимо выполнять подстановку графа блока в лексический контекст
+вызывающего метода в зависимости от того как происходит работа с блоком в теле обработчика сообщения.
+
+Never
+    Блок не учитывается в выводе типов
+
+Once
+    Блок подключается параллельно инструкции, принимающей его параметром, например 1 to: 10: do: [ ... ]
+
+Maybe
+    То же, что и для Once, но есть параллельное ребро мимо блока
+
+Multi
+    То же, что и Multi, но еще добавляется возвратное ребро в начало блока
+
+Escape
+    Вызовы этого типа не могут быть представлены в виде графа и блокируют вывод типов для задействованных переменных
+
+После построения inline графа, выполняется проход TauLinker-а на нем,
+полученные тау узлы могут быть использованы для вывода типов переменных.
+
+
+Итак, алгоритм.
+
+Для метода, в лексическом контексте которого объявляется блок:
+    1. Получаем список переменных, которые мутирует блок (известно после анализа графа блока)
+    2. Выполняем анализ для каждой посылки, которая использует блок как параметр
+    3. В точку вызова передаем тип всех временных переменных, используемых блоком (как аргументы)
+    4. После анализа посылки изучаем контекст на предмет поменявшихся типов переменных
+    5. Если тип поменялся, то маркируем текущую посылку как мутатор
+    6. После маркировки всех мутаторов обновляем тау узлы графа и точки их использования
+    7. Пересчитываем все заново с обновленным графом (новых мутаторов добавиться не должно)
+
+Для метода, принимающего литеральный блок параметром:
+    1. В каждой посылке, использующей переданный аргументом блок выполняем анализ «как есть»
+    2. Аккумулируем типы меняющихся переменных
+    3. Возвращаем аккумулированный результат
+
+Для методов Block>>value* (код обработчика примитива 8)
+    1. Проводим анализ блока, передав типы аргументов и переменных
+    2. Получаем типы переменных и результата
+    3. Возвращаем все добро наверх
+
+
+Проходы анализатора, в зависимости от типа метода:
+    1. Метод, не содержащий ветвлений доказывается за 1 проход
+    2. Метод, с литеральными условиями при ветвлениях доказывается за 1 проход
+    3. Метод, не содержащий циклов (обратных ребер) доказывается за 1 проход
+    4. Метод, содержащий циклы, но не имеющий тау узлов с обратными ребрами, доказывается за 1? проход
+    5. Метод, содержащий циклы и имеющий циклическую зависимость по данным (x <- x + 1), доказывается за 2 прохода
+
+    6. Метод, содержащий литеральные блоки, вне циклов: если нет замыканий или только читают — 1 проход, если пишут — минимум 2 прохода
+    7. Метод, содержащий литеральные блоки, в циклах — минимум 3 прохода
+    8. Метод, содержащий литеральные блоки, записанные в переменную
+
+    Блоки, вызываемые несколько раз (утекающие в поле) не могут быть выведены, без отслеживания полей
+
+    9. Метод, содержащий литеральные блоки, утекающие в неизвестность — полная блокировка вывода переменных, которые они пишут
+
+
+Алгоритм анализатора:
+    1. Делаем базовый проход без обратных ребер
+    2. Если предыдущий проход вывел возврат по литеральному пути и метод не содержит блоков мутаторов — выход
+    3. Делаем базовый проход с нетривиальными мутаторами
+    4. Если есть литеральный возврат — выход
+    5. Делаем индукционный переход
+