Здравствуйте, Sinix, Вы писали:
AC>> 1.Каковы недостатки, такой модели и системы типов?
S>1. Непонятно, какие проблемы решает такой подход. Точнее, чем он лучше тысячи и одного велосипеда?
По видимому не чем, но мне интересна эта тема.
S>2. Неочевиден смысл введения кучи сущностей.
Что вы имеете ввиду? Я наоборот стараюсь свести их число к минимуму, но без потери возможностей.
S>2.Чем контейнеры принципиально отличаются от глобальных переменных?
Они ближе к контейнерам из STL нежели на классические переменные, к тому же будут в основном локальными.
S>2.Если это они и есть — зачем изобретать новые термины?
Новые термины нужны чтоб избежать путаницы. Читатель встречая в тексте новый термин или использование не совпадающее с ранее известным значением,
думает "WTF?" и лезет в документацию смотреть, ну или закрывает вкладку браузера
Но оба эти варианта лучше чем, по ходу чтения, каждый раз он будет думать "Это ведь переменная, какова с ней происходит?".
S>3. Насколько я понимаю, методов как таковых не существует, всё — на каллбаках. Круто, но, опять-таки — зачем?
Методы есть но более высоком уровне(уровне модулей), потому использоваться они будут гораздо реже чем в ООП например. Методы это также контейнеры.
S>4. Неплохо бы увидеть описание структурных типов. Для начала — как будет выглядеть тип Screen, имеющий произвольное разрешение в пикселях (Pixel)?
Ох, это обширная тема
Поддержка структурных значений(не типов, так как структурное значение может и не иметь типа а быть собранным "налету"), является базовой возможностью, структурные значения называются "пакеты".
Пакет — это монолитное структурное значение, состоящие из группы значений примитивных типов и/или вложенных пакетов, то есть операции выполняются над всем пакетом а не над отдельными элементами.

Пакет может содержать неизвестное, на момент компиляции, число элементов но эти элементы должны иметь одинаковы тип.
Далее, контейнеры длятся на:
1.Примитивные — могут хранить только одно значение.
2.Структурные — могут хранить много значений.
Всего три вида:
"ARRAY" — Могут быть многомерными, обращение только по номеру элемента.
"UNION" — Только одномерные, обращение по номеру и по имени элемента.
"HEAP" — Одномерные, обращение только по номеру элемента, произвольное число однотипных элементов.
Контейнер "статический" если не содержит и не является "HEAP", иначе "динамический".
Число элементов и выход указателей за границы проверяются динамически, типы значений статически.
Если пакет и контейнер имеют одинаковую структур(число, тип, положение элементов), то пакет может быть помещён в контейнер(структурная типизация).
Таким образом для работы с, например, битмапом произвольного размера необходим динамический контейнер который может быть определён так:

\\Опеределения
  Screen UNION[                  \\Структурный контейнер
              Height INT         \\Высота
              Width INT          \\Ширина 
              Bitmap HEAP PIXIL  \\Куча пикселей 
              ]
\\Код
  Resise(Screen,640,480) => Screen \\Подгонка размера изображения

Пример определения процедуры для работы с изображениями:

IMAGE PACKEG[INT, INT, HEAP PIXIL]   \\Чтобы каждый раз не описывать пакет определим для него тип, 
                                     \\можно использовать этот тип также для определения контейнера и писать просто: Screen IMAGE
PROCIMG CODE [IMAGE,INT,INT][IMAGE]  \\Тип для значения-код, тот тип можно использовать для любых процедур имеющих такие же аргументы и результат.
Resise PROCIMG (Image,Height,Width){\*Код изменения размера*\}(NewImage)  \\Контейнер типа "PROCIMG" с начальным значением.

AC>> 2.Жизнеспособно ли это в принципе?
S>Без вводной части и обоснования всех введённых концепций/терминов — нет.
Мы работаем над этим
AC>> 4.Неявное приведение типов, насколько оно нужно?
S>It depends. Если под ним понимается возможность неявного приведения без потерь — из byte в int или из Time к DateTime (при условии явного объявления implicit cast operator) — пойдёт. Если имеется в виду, что корректность любого присваивания будет проверяться динамически, в рантайме — велкам к скриптовым языкам и прочей мелочи.
Именно возможность приведения без потерь. Вопрос в том покроет ли полиморфизм процедур/операторов эту возможность?