Что-то типа спецификации метаязыка, описывающего синтаксис конструкций языка Валентина:

Как и в первой Валентине, такое описание можно преобразовать к форме близкой к БНФ  автоматом. Плюс сменяемый синтаксис предполагает возможность включения исходников на разных диалектах (это возможно, но реализацию надо продумывать).

Вопросы трансляции.
Теперь когда немного ситуация проясняется в вопросе реализации синтаксиса, встает вопрос в описании P-кода. Смысл P-кода в том, что разбор интерпретатором всех возможностей синтаксиса может требовать некоторые ресурсы, что в целом медленно (интерпретация всегда по определению медленней компиляции), тогда как во внутреннем автоматном представлении нет смысла в реализации всех возможностей нужных человеку. Идея заключается в сужении множества представления текста программы в однозначное и очень краткое описание инструкций. Например, описание такого рода:

Здесь символ i признак начала новой инструкции
3 - идентификатор инструкции (команда ID в метаязыке, указывающая на семантику)
1>...4> список входящих параметров конструкции (конструкция языка может содержать 8 слов и 4 параметра).
Как видно из схемы первого поста, если добиться правильного описания инструкций, имеется теоретическая возможность сохранения состояния виртуальной машины в любой момент времени (например, приостановили программу, перенесли программу на другую систему, запустили).

В целом это немного смахивает на платформу .Net

Сама программа условно делится на две части:
1. Инициализация начального состояния виртуальной машины (в исходном тексте программы это раздел описания системы)
2. Подпрограммы для исполнения виртуальной машины (в исходном тексте программы это раздел с описанием функций)

Ну так вводите эти данные в чем проблема? В примере есть цикл, это что, не оператор управления?

Не знаю никакого Д-кода .

Парсеру вообще пофиг он просто распознает конструкцию и возвращает ИД с параметрами. А как распознают ИД в виртуальной машине уже другой вопрос. Поэтому сейчас можно создавать любую конструкцию - хоть оператор, хоть заголовок функции, хоть объявление переменных.

Ну это зависит от того нужно Вам это или нет. Компилятору наверно надо хранить такие данные, чтобы помнить все. А интерпретатору нет смысла откладывать решения в какие-то таблицы. Большинство литературы она про компиляторы поэтому и разночтения получаются.

Да, это называется экономия на спичках. Большинство менеджеров памяти выделяют место странично кратно 4 (иногда 2). То есть если Вам надо 7 байт, Вам дадут 8, как бы Вы не мешали данные в record'ах. Перемешивание данных имеет смысл для границ страницы (то есть расположить так чтобы каждое поле по возможности располагалось в одной странице предоставляемой памяти иначе компилятор просто перенесет поле на новую страницу самостоятельно). Опять же это про компиляторы. Просто так упорядочивать (типа сначала Integer, потом Byte) бесполезно. И я уже молчу об операционках, они выделяют память программам блочно. И пофиг как Вы будете выравнивать свои структуры - надо Вам 25 Кб памяти, операционка Вам даст 32 Кб. Хоть выравнивать record, хоть нет. Смысл в такого рода экономии весьма и весьма сомнителен.
И дополнительно - то что я должен в ручную распихивать порядок в record'ах это вообще говоря косяк компилятора. Он что сам не может автоматически правильно распихать? Может, вся информация у него для этого есть. Почему я должен это делать ручками? Ладно интерпретатору надо торопиться исполнять инструкции, компилятору-то вообще без проблем оптимизировать порядок полей в record. Отсутствие такой возможности просто признак неоптимальности работы компилятора и только. Это прямая вина разработчика конкретной реализации. А язык и тем более программист не должны вообще обращать внимания на эту проблему.

Никаких ВинАпи, Вы что кроссплатформенность же. Менеджер для работы с библиотеками приводит данные в правильный вид, а все безобразие должно твориться в динамических библиотеках. Вычислительная модель оторвана от платформы.

Может быть да. Я поэтому и пишу это здесь, чтобы избежать грубых ошибок проектирования.
Тут тебе и метки, и особый сорт меток как имена функций

С точки зрения парсера нет никакой разницы между break и continue - будет возвращен ИД и параметры (ну в данном случае без параметров). А семантика уже рассматривается дальше.

Состояние хранится в виртуальной машине. Нет проблем. Рассматривайте вычислительный процесс как дерево, в результате вызов функций и состояния накапливаются рекурсивно. Противоречий не возникает, парсеру нет смысла помнить состояние, для данного оператора также возможен возврат идентификатора конструкции.
Вы смотрите на более крупный блок управления. Я в данный момент описываю трансляцию с описанного программистом синтаксиса в более узкий синтаксис виртуальной машины. Хранить там состояния нет смысла.

Внутри языка этого нету, проблема решена бритвой Оккама .

Лямбды противоречат концепции языка - все является системами, все системы обязаны иметь адресацию для возможности доступа к ним и реализации основных функций, таких как копирование, удаление, определения природы системы и т.д. на этапе исполнения программы. Потому что если система имеет десять безымянных функций, как определить какую из этих десяти требуется скопировать в другую систему? Или передать в качестве параметра в другую функцию. Я понимаю да, что лямбды прямо в вызове описываются. А если я хочу одну и ту же функцию в десять других распихать? И зачем мне этот геморрой десять раз безымянно описывать? Не, не, не. Я понимаю для статики можно мапом пробежаться, но система-то динамическая, я не знаю что нужно передать в мап-функцию, чтобы она смогла туда передать лямбду. Я не знаю какую лямбду будет требоваться передавать - это может стать известно во время выполнения программы. В данной модели вычислений претензий к лямбдам просто вагон и маленькая тележка.

Это не требуется для реализации алгоритмов. Это просто жертвоприношения компьютерам и не больше. Разве, например, в алгоритме калькулятора нужен атрибут STDCall? Нет, там нужно получить два числа и произвести над ними операцию. Вывести на экран в конце-концов. Никакой STDCall там не требуется.

Это костыли для решения проблем созданных ранее. Виртуальные функции имеют ограниченный функционал. Системы можно переименовывать, а функции это системы. Я могу любую функцию переименовать в ту, какую нужно, скопировать функцию в систему, построить систему методом прямого копирования. Виртуальная функция в таких условиях вообще теряет смысл. Безымянные и анонимные функции суть те же лямбды в различных ипостасях. А значит не нужны (в данной языке разумеется, в иных случаях это полезная фишка). Безымянная функция в Дельфи это костыль, решающий проблемы жесткой системы типов. Также как и Variant. Сначала создадим бастионы, а потом наделаем там потайных ходов. Ну им это нормально, так как они тянут за собой совместимость со старьем. Мне-то зачем? Я ничем не связан и сразу могу делать как хочется. И плюс у меня есть возможность анализировать их ошибки (у них такой возможности не было) и свои ошибки первой Валентины.

Вот именно это язык и делает, только с объектами внутри, а не в межпроцессорных взаимодействиях. В случае необходимости будет написана оболочка для согласования различных моделей между собой.

На данный момент СуперВселенная 1 обзавелась двумя ветвями:
- 0 - описание систем
- 1 - ветвь исполнения программы
В 0 извлекаются все системы из внешних модулей, затем запускаемая система будет копироваться в 1, выполняться конструктор, а затем старт системы по точке входа.
Любые упоминания систем из внешних модулей в функциях будут копировать описания систем из 0 в соответствующую ветвь исполнения. Гибкость такого подхода в том, что в разных модулях можно многократно ссылаться на одни и те же внешние модули - их можно скопировать только один раз при первом упоминании . Работа ведется в соответствии с моделью - один исходник - много систем (обсуждалось ранее). Таким образом, допускаются разные системы с одинаковыми именами в разных модулях. Обращение к описаниям систем (например для копирования) из внешних модулей требует обязательного упоминания имени модуля.

Здесь main(.vlt) имя файла с исходником.

Где и как искать подключаемые внешние модули?
Пока предлагается такая стратегия:
1. Ищем в каталоге с программой. Если там найдем, то его и грузим.
2. Ищем в специальном каталоге с интерпретатором (там по идее должна храниться библиотека модулей, реализующих базовые возможности, чтобы не писать их каждый раз ручками)

Приоритет расширений. Тут такая вещь, предполагается, что модуль указывается без расширения, а интерпретатор настолько умный, что сам его подставляет. Но я же либерал и демократ, а потому предлагается их несколько на выбор. Итак, что грузим сначала в порядке убывания:
1. Расширение *.влн (типа сокращения от Валентина)
2. Расширение *.влт (аналогично)
3. Расширение *.vln (Valentina)
4. Расширение *vlt (аналогично)
5. Просто файл, без расширения

Тут конечно волею хаоса может быть в каталоге два файла с одним именем и разными расширениями. Ну что поделаешь, не судьба , кто-то должен грузиться первым.
Если возражений нет и не предвидится, то так и станет в ближайшие пару дней. Я предупредил

Появилось немного свободного времени и появились первые результаты:

Теперь я могу создавать простенькие подсистемы на этапе описания программы. То есть это пока, что аналоги простых переменных. На данный момент это такой оператор +, на большее фантазии не хватило пока. В нем можно будет добавлять переменные списком и с присвоением простых значений, например:

Пока проблема в перечислении, скорее всего там будет не запятая, а точка с запятой. Иначе придется в числах использовать точку в качестве разделителя. В общем это требует обсуждения. Что использовать разделителем в числах? Точку или запятую? Я планировал оба варианта наравне. То есть допускается складывать 0,5 + 0.1 Результат всегда один разделитель, какой-нибудь (или всегда точка или всегда запятая).

После некоторых размышлений, я пришел к выводу что функцию стоит рассматривать как систему, параметры которой также подсистемы (что было понятно и ранее). Касательно конкретики - входящие параметры будут находиться в подсистеме @, результат в #. Зачем это нужно - для удобства. Теперь у программиста будет возможность использовать входящие параметры без учета их имен. То есть имея стандартную операцию перебора элементов коллекции (в нашем случае ветвей дерева @) нам не обязательно знать как называется тот или иной параметр. Теоретически мы можем как-то маркировать функцию, так чтобы она могла работать с неограниченным количеством параметров. Ну например, в синтаксисе предусмотреть типа: функция Х обработки ряда. Такую функцию можно использовать когда количество параметров и их расположение не имеет значения. Ну, например, это сумма, функция map и т.д. Параметры внутри функции можно именовать как-то стандартно (например, для функции Х это будет Х1, Х2 и т.д.), но для данной функции важно, то что она просто обрабатывает поток данных, имя конкретного элемента не важно в алгоритме.
Таким образом, входя в функцию, мы сразу же получаем две подсистемы (пока синтаксис условный) @ и #, и дальше объявленные внутри функции подсистемы. Из функции можно будет читать параметры, напрямую, зная их имена, либо перебирать их в цикле, типа for...each. Мне кажется это ближе к математической интерпретации функции.
В общем это можно трактовать как будто это функция в которую передается массив с произвольным числом элементов.