Да хотя бы в Future of Programming. Мол штуки не должны взаимодействовать через API, вместо этого коммуницируя и находя общий интерфейс на лету.

https://www.youtube.com/watch?v=8pTEmbeENF4 <- вот здесь

Мне не кажется, что он при этом имел в виду подобное чудище... 😊

Ну я говорю „похоже“. Ну и я кстати не понял что он тогда под этим имел в виду, на самом деле.

Вот пример описания схемы изображения вместе с самим изображением шахматного узора 2x2, используя только 1 бит на пиксель.

@struct {
Image := @struct {
    ImageColorType = @type{}
    ImageWidth = @uint16{}
    ImageHeight = @uint16{}
    ImagePixels = [ImageHeight][ImageWidth]ImageColorType{}
}

BlackOrWhiteColor := @struct {
    Luminance = @bit{}
    R := Luminance
    G := Luminance
    B := Luminance
}

CheckerImage := Image{}(
    ImageColorType = BlackOrWhiteColor
    ImageWidth = 2
    ImageHeight = 2
    ImagePixels = {
        {
            {{0}, {1}}
            {{1}, {0}}
        }
    }
)
}{}

У цвета есть поле яркости и алиасы на него для красного, зелёного и синего.
Если нужен 24-битный цвет, можно вместо алиасов сделать каждое поле отдельно:

Color24 := @struct {
    R = @norm8{}
    G = @norm8{}
    B = @norm8{}
}

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

Чёрт его знает, что конкретно он имел в виду, но исследования в сторону service discovery и self-describing data идут всю дорогу и продолжают идти. Даже "индустрия" пыталась что-то такое внедрить сначала для XML Web Services со всякими WSDL, потом Semantic Web с онтологиями, сечас скотились просто к микро-форматам.

@struct {
Image := @struct {
    ImageColorType = @type{}
    ImageWidth = @uint16{}
    ImageHeight = @uint16{}
    ImagePixels = [ImageHeight][ImageWidth]ImageColorType{}
}

BlackOrWhiteColor := @struct {
    Luminance = @bit{}
    R := Luminance
    G := Luminance
    B := Luminance
}

CheckerImage := Image{}(
    ImageColorType = BlackOrWhiteColor
    ImageWidth = 2
    ImageHeight = 2
    ImagePixels = {
        {
            {{0}, {1}}
            {{1}, {0}}
        }
    }
)
}{}

Color24 := @struct {
    R = @norm8{}
    G = @norm8{}
    B = @norm8{}
}

интересно а реально ли такое использовать для серилизации из json в бинарный формат и обратно (+ проверка на корректность)

еще было бы забавно упаковывать саму схему вместе с данными

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

По умолчанию схема и будет вместе с данными, в примере выше так и есть. А при желании их можно разделить.

а где можно глянуть реализацию?

Коммерческая тайна

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

Один фиг придется переписывать и переделывать

Сериализовать JSON в такой файл теоретически реально, но в самом JSON мало информации о типах (number, string, object). Надо либо написать свою схему, где будет указаны int/float и битность типов, либо всё по дефолту будет в даблах и т.п..
А сериализация бинаря в JSON вообще без проблем, потому что в бинаре информации более, чем достаточно.

Что то вроде описания протобуфера или это будут констрейны а-ля пролог?

Там очень много всего взаимосвязано. Даже минимальный рабочий прототип в принципе не сделать, не продумав все детали.

в любом случае успехов

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

Спасибо

Надо погуглить, что есть про self-describing data, такие ключевые слова я ещё не пробовал вводить...