Матчинг по конструкторам, а не по типам.

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

Собственно, деконструкторы на значения в полях смотрят только если это явно сказано, типа match (cons a (cons b L)), поэтому тут нет зависимости от стратегии вычислений и конечности/бесконечности/зацикленности списков.

На 1/2 это всё уже есть в рамках одного курса Design Concepts in Programming Languages, где почти всё это разобрано и хорошо структурировано (в отличии от многих учебников). В DCPL не хватает только прагматики: платформеннозависимых оптимизаций, сборки мусора, ВМ. Фактически, всё заканчивается там на SSA-представлениях, откуда можно начинать курс по оптимизациям для конкретных машин.

А, да, парсинга ещё нет во всех его проявлениях. Но, вроде как, других учебников по парсингу предостаточно.

То есть, не нужно делать 6 различных курсов. Хватит 3-ёх.

1. Парсинг (хотя, разве всё ещё не изобретены всевозможные грамматики, которых достаточно?).
2. Теория языков программирования (включая динмическую и статическую семантики, теорию типов, компиляцию в SSA, стратегии вычислений и всё-всё-всё). Но это годовой курс, конечно.
3. ВМ, рантайм, оптимизации.

Можно ли об этом можно почитать подробнее?

Ну. Собственно, о том и речь, что популярность языка определяется совсем не его возможностями.

Что-то не могу найти — не помню где читал. В принципе, есть вообще RustBelt, хотя это уже немного другое.

Вполне по теме. Хотя бы ради работы вместе с Eelco Visser и Peter Mosses стоит туда пойти :)

Пока это выглядит, как попытка внедрить свою прослойку, организовать под своим началом тех, кто действительно делает что-то по существу :) IR уж очень заурядный и примитивный.

В то время, когда я искал материалы по замечательному PLT Redex, я наткнулся на вот этот проект: https://github.com/lkuper/rust-redex

А чего не хватает? Бинарная и арифметическая логика есть, мультиплексирование есть, CF (phi, branch, call) есть, halt есть, сигналы и прерывания есть, работа с памятью, стеком и регистрами есть. Кроме того есть даже сложные типы как Array и Struct, не говоря уже про Pointer и Signal

Допустим, у меня есть свой DSL для высокоуровневого описания архитектуры ускорителей. Что мне нужно сгенерировать для этого LLHD, чтобы сохранить параллелизм памяти?

Не кажется, что чего-то тут не хватает? :)

То есть не хватает метаданных?

Сдвига? Выравнивания?

Отношения порядка между операциями с памятью. Получается, как и в обычном LLVM, у нас порядок прямо указан текстуально. Никакого параллелизма.

Ну указан прямо да, чем это плохо?

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

В целом, в отличие от программных решений, в "железных" проектах почти все связано с параллелизмом. Многопортовые блоки памяти уже давно не редкость и вот этот вариант — одно обращение к памяти за такт, архитекторов вряд ли устроит :)