фронт для LLVM для приятного для самого разработчика синтаксиса, решающего наоборот _узкую_ задачу, или транслятор в С++/Java  (типа собственного языка для GUI + Web) — задача уровня приличной курсовой для ИТ специальности, максимум — глава с "мясом" для дипломной работы

Легко ли на LLVM ложатся динамические языки? И позволяет ли фронт для LLVM полу/автоматически сделать поддержку этого языка в редакторе?

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

ну вот компашка имеет свою банку с икрой на разработке legacy-транслятора:

Подобных "компашек" немало, наверное, если по тёмным углам поискать. ;)
Но похоже, что на практике всё почти всегда решается так, как пишет @impworks

Ну. Вот физики написали себе Julia. Очень ей довольны. Думаю, если целевая аудитория загружена другой математикой, то им заходят динамические языки, потому что не надо вкладывать существенные усилия ещё и в сложную теорию языка (и не интересно, и времени нет). Ещё подтверждения гипотезы: математики написали себе Sage на Python, у числовых теоретиков популярна Scheme, датасаейнтисты сидят в Python, финжиры используют APL.

IMHO, имеет смысл сделать что-то типа immutable scheme (js, python, etc ...), потому что мутабельность и многопоточность ограничивают возможности оптимизации и анализа кода. В эту сторну вполне можно развивать современную динамическую мысль.

динамического хаскеля не хватает :(

Имеется в виду чистая функциональность вместе с IO?

dynamic + lazy + immutable, а IO можно пер модул ограничивать, если надо

Если lazy, без IO не обойдётся. Но так-то тоже вариант

но тут же руками надо delay i force делать? а хочется по дефолту

как в #racket/lazy

На хаскеле можно писать так, в чем проблема то?

Зависти библиотеку с universe типом, как в динамических ЯП и вперёд. Делается ну совсем не сложно

а можно пример?

Вспомнить бы блог пост в тему, был неплохой, где переизобретался общий тип из схемы

Но в целом идея сделать data с тегами и оптику для доступа к полям, после этого можно все функции обернуть в динамические.  Если понимать почему динамические языки это untyped, то алгоритм понятен. Но могу вечером и пост поискать и расписать подробнее