а можно с примером, что такое "контекст" и как это было бы полезно? я пока не понимаю. например, если число 1 - это объект класса int, то как его можно evaluate и к чему apply?

JavaScript такой

Object => Primitive => Int
Primitive.eval(context:Object) -> self

но

Primitive => Symbol
Symbol.eval(context) -> context[self.name]

меня наверно Вольф Рам укусил, все тянет в какие-то странности с графовыми процессорами

коллеги а поделитесь ссылкой на какой-нибудь раст-чат для тупых вопросов, пожалуйста (телеграм, дискорд, irc, рус/англ)

https://dev.to/danlebrero/the-broken-promise-of-static-typing про юнит-тесты и языки

Странно, что сюда не закинули

https://jason-williams.co.uk/a-possible-new-backend-for-rust

http://lucacardelli.name/TheoryOfObjects.html смотрели?

Вам, скорее всего, сюда: https://t.me/rustlang_ru
Это если не официальный и по-русски.

Как поставить точку в вековом споре ДТ/СТ:

1. Изобрести абсолютно бессмысленную метрику
2. Убедиться, что она не показывает преимущества статической типизации над динамической
3. Объявить, что раз преимущество не выявлено данной метрикой, его стало быть и нет

там комменты ещё любопытные

Скажите, а разрабатывался ли подход перевода низкоуровневого кода на каком-нибудь Коболе в высокоуровневый на неформальный язык? Или, скажем, слабоформализованный, но понятный людям с каким-то образованием.

То есть, компилятор не для понимания текста машиной, а для человека? Ida pro не предлагать.

Cobol вполне высокоуровневый, это, кстати, один из первых DSL. А как Вы будете проверять корректность такой трансляции?

Я не знаю. Ну будь задача полностью поставлена, ее давно бы уже решили! 😉

Вообще есть разные средства анализа, которые строят, скажем, графы вызовов и не сильно заморачиваются насчёт корректности. Тот же Doxygen часто лажает, сливая разные классы с одинаковыми именами в один на диаграмме, и всё равно остаётся полезен.

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

Примерно год назад мне пришлось объяснять работу метапрограммирования на С++, и выяснилось, что проще всего это сделать, объяснив, что такое term rewriting, а дальше просто перевести конструкции C++ на, в общем-то, язык Miranda. Перевод нестрогий, надо сказать.

А зачем? Какую задачу это решит?

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

А в качестве "псевдокода, который можно реально выполнить" уже существует Python :)

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

На самом деле, трансляция в представление, которое служит только иллюстративным целям, вполне используется. Есть различные инструменты, которые делают PL -> LaTeX. Можно вспомнить тот же PLT Redex. Результат обычно вставляют в статью :)

Но это вроде бы в основном диаграммы, а не языки.

Вот два примера вполне себе языков: SPIRAL, Fortress.