LINUX.ORG.RU

История изменений

Исправление SZT, (текущая версия) :

Гомоиконность, убийца сишечки, полный стек... Тьфу!

Конечно же нужен язык с гомоикнностью. Нужно сделать на самом языке систему символьных вычислений (ССВ) над его же кодом/AST и используя эту ССВ иметь возможность например выводить определенные свойства реализации (для проведения формальной верификации, доказательства корректности, как например с использованием Frama-C с применением SMT-решателей, Coq, HOL и всякого такого), использовать эту ССВ для целей вроде суперкомпиляции/супероптимизации. Или чтобы циклы например анроллить, типа вот мы задаем каким-то там макаром, что вот тут у нас цикл, и говорим нашей ССВ что вот наанроль его вот таким образом, и потом будет там наанроленный цикл. Или реализовывать свои domain-specific оптимизации для каких-нибудь бигинтов. Или эту же ССВ можно попросить, чтобы например она трансформировала код некой функции таким образом, чтобы она вместо int принимала long long int, чтобы это было еще в IDE интегрировано нормально, и чтобы такую кодогенерацию при желании даже в рантайме можно было бы делать, если с собой в рантайм тащить еще JIT с VM (т.е. тащить какую-то жирную хрень типа JVM) и AST, удобный для трансформации. Можно сделать что-то вроде тех же Java оптимизаций в рантайме, рантайм-профилирование и трансформация кода в процессе. Или даже profile-guided optimisation (PGO) потом сделать на основе собранной статистики, т.е. вот типа набрали мы статистики при выполнении кода в VM и потом использовали ее чтобы полностью четко скомпилировать в бинарник, чтоб без VM все выполнялось. Чтобы можно было бы вводить свои правила приведения типов, и на основе этого ССВ могла бы выводить тип. Или чтоб можно было сделать язык с нестрогой типизацией поверх существующего AST и чтоб в рантайме при каких-нибудь тестовых прогонах производился мониторинг того, что с какими типами вызывается (т.е. к каким фактически типам там приводится все в динамике) и потом чтобы на основе этого можно было бы расставить эти самые типы в реальном коде. Т.е. если у нас будет функция без указания типа, и эта функция в одном месте вызывается допустим с типом int, а в другом с типом float, то можно сделать две специализированные под этот тип реализации, которые бы вызывались конкретно в тех местах, где собственно и происходит вызов той функции с таким-то там типом.

Насколько я понял, ничего подобного в этом Red, REBOL нет, так что ненужно

Исходная версия SZT, :

Гомоиконность, убийца сишечки, полный стек... Тьфу!

Конечно же нужен язык с гомоикнностью. Нужно сделать на самом языке систему символьных вычислений (ССВ) над его же кодом/AST и используя эту ССВ иметь возможность например выводить определенные свойства реализации (для проведения формальной верификации, доказательства корректности, как например с использованием Frama-C с применением SMT-решателей, Coq, Agda), использовать эту ССВ для целей вроде суперкомпиляции/супероптимизации. Или чтобы циклы например анроллить, типа вот мы задаем каким-то там макаром, что вот тут у нас цикл, и говорим нашей ССВ что вот наанроль его вот таким образом, и потом будет там наанроленный цикл. Или реализовывать свои domain-specific оптимизации для каких-нибудь бигинтов. Или эту же ССВ можно попросить, чтобы например она трансформировала код некой функции таким образом, чтобы она вместо int принимала long long int, чтобы это было еще в IDE интегрировано нормально, и чтобы такую кодогенерацию при желании даже в рантайме можно было бы делать, если с собой в рантайм тащить еще JIT с VM (т.е. тащить какую-то жирную хрень типа JVM) и AST, удобный для трансформации. Можно сделать что-то вроде тех же Java оптимизаций в рантайме, рантайм-профилирование и трансформация кода в процессе. Или даже profile-guided optimisation (PGO) потом сделать на основе собранной статистики, т.е. вот типа набрали мы статистики при выполнении кода в VM и потом использовали ее чтобы полностью четко скомпилировать в бинарник, чтоб без VM все выполнялось. Чтобы можно было бы вводить свои правила приведения типов, и на основе этого ССВ могла бы выводить тип. Или чтоб можно было сделать язык с нестрогой типизацией поверх существующего AST и чтоб в рантайме при каких-нибудь тестовых прогонах производился мониторинг того, что с какими типами вызывается (т.е. к каким фактически типам там приводится все в динамике) и потом чтобы на основе этого можно было бы расставить эти самые типы в реальном коде. Т.е. если у нас будет функция без указания типа, и эта функция в одном месте вызывается допустим с типом int, а в другом с типом float, то можно сделать две специализированные под этот тип реализации, которые бы вызывались конкретно в тех местах, где собственно и происходит вызов той функции с таким-то там типом.

Насколько я понял, ничего подобного в этом Red, REBOL нет, так что ненужно