что то WinFS не к месту вспомнилась... тут как бы и структурированные хранилища данных рядом лежат, а не только API

Если вопрос о типах, то Б. Пирс: Типы в Языках Програмирования. TAPL

ps: для IoT проблема форматов сейчас критична кстати, именно в плоскости обмена между произвольно взятыми нодами и выборки/хранения — необходимо средство генерации кода для очень слабых микроконтроллеров, симметричные бинарные парсеры, никакой сериализации, пакеты данных порядка 50 байт

MsgPack?

в msgpack байтовые пакеты, нужна адресация битовых полей, 3 бита, 9 бит, big/little endian и т.п.

чтобы можно было _напрямую_ выразить любой формат любого устройства (счетчики, датчики,..), протокола обмена по SPI/UART/MODBUS/... формата файла или образа файловой системы (ресурсивно)

хотя бы http://kaitai.io/ но лучше еще и с гибкой типизацией

вот только  не надо мне в микроконтроллер iostreams, пожалуйста https://github.com/kaitai-io/kaitai_struct_cpp_stl_runtime/blob/3338c1a43f7dda59e1766263b86455103b5ade86/kaitai/kaitaistream.cpp#L25

LLVM, в крайнем (или не очень) случае Rust для читаемости

Кстати, не кажется ли вам, что в bash очень здорово решена проблема ленивости? Если это внешний вызов - то есть, очень длительный, данные передаются лениво через |, а если это внутренняя процедура, то энергично. Собственно, нужно только сделать ленивым вызов через `` и будет отличный компромисс.

а причем тут bash, ленивость и то как передаются данные через пайп - у пайпа есть писатель, читатель и размер внутреннего буфера (обычно 16 страниц по 4КБ). Получатель не прочтет с темпом большим чем писатель запишет, и наоборот (в пределах 64КБ окна). Шелл тут вообще не при делах. IMHO

в досе были пайпы

они были реализованы через запись в промежуточный файл

и поэтому не были ленивыми

поэтому шелл COMMAND.COM делал пайпы нелениво, и это было сознательным выбором, а не «достигалось автоматически»

И "сознательный выбор" учитывал тот факт, что MS-DOS 2.0 была однозадачной ОС :)

В данном случае, это неважно, что | реализованы с помощью поддержки OS. Интересно другое - в ленивых языках достаточно сложно решить, какие же именно вызовы делать ленивыми, а какие-энергичными для достижения максимальной производительности. В скриптах есть вызов внешних процедур, который разумно делать по-умолчанию ленивым, а вот внутренние процедуры разумно делать полностью энергичными. Так?

То есть, если мы делаем высокоуровневый язык, разумно делать ставить такие умолчания - для внешних вызовов (FFI, скажем) ленивые, а вот внутренние процедуры по-умолчанию энергичные? Или нет?

разумеется

Pipe-ы к ленивости имеют чуть меньшее отношение, чем никакое. Это конструкция из pi-исчисления, а не из lambda-исчисления.

Автоматически решать в ленивых языках, что считать энергично, а что лениво, действительно, достаточно сложно, но, обычно, всегда у программиста есть seq, или аналоги, которыми он может явно управлять. Соответственно, обратная ситуация. В энергичных языках тоже нынче есть средства управления ленивостью. Вот в Clojure, например, последовательности ленивы по-умолчанию. В Схемках есть lazy, и т.д., и т.п. В Haskell же могучие эвристики определения того, нужно ли считать лениво или нет. Оптимальная редукция графов, всё такое.

Bash же - это энергичный язык. Но он энергично работает с процессами, а не со значениями. В этом есть, мне кажется, интересный, любопытный и полезный момент.

Раскройте, пожалуйста, тему «с процессами, а не со значениями»