Метапрограммирование в Rust

изменить код программы во время ее выполнения?

Вообще, CL здесь — плохой пример. Его возможности, как раз в данном аспекте, сильно ограничены. Это характерная черта интерпретируемых языков, например newlisp:

(define (f)
  (begin
    (println (inc cnt))
    (push (last f) f -1)
    (if (> (length f) 3) (pop f 1))))

(f)

там на самом деле код - это данные. А в CL это просто базворд. Там код доступен только на время компиляции, никакого полноценного рантайм-метапрограммирования (aka рефлексии) там нет. Насчет раста не знаю, но тоже вряд ли.

а в D есть такое?

Можно ли изменить код программы во время ее выполнения?

можешь открыть секцию .code для записи

Не знаю, врать не буду.

например newlisp

А можно описать, что делает (или должен делать) этот код?

Можно ли расширять компилятор, писать DSL'и, работать с AST?

Да.

Можно ли изменить код программы во время ее выполнения?

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

Насколько мощно?

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

Вот немного ссылок, которые сразу вспомнились-нашлись:

• http://doc.rust-lang.org/guide-macros.html - руководство по обычным макросам.
• http://doc.rust-lang.org/guide-plugin.html - руководство по написанию плагинов к компилятору. Это уже посложнее, зато есть возможность как угодно модифицировать синтаксическое дерево. Тут документации не так много и эта часть языка, насколько я знаю, довольно активно меняется.
• http://doc.rust-lang.org/syntax - немного автоматически генерируемой документации по парсеру, ast и макросам.
• http://doc.rust-lang.org/rustc/plugin - тут еще немножко автоматически генерируемой документации по созданию плагинов.

  http://rustbyexample.com/staging/macros.html - недописанная глава про обычные макросы из Rust by Example.

Очевидно, нет, потому что D — тоже компилируемый язык.

На ходу дописывает тело функции внутрь (begin ...)

Можно ли изменить код программы во время ее выполнения?

Изменить нет, но добавить можно:

http://www.hydrocodedesign.com/2014/01/17/jit-just-in-time-compiler-rust/

В CL можно сделать так

(defmacro defun* (name args &body body)
   `(progn
       (setf (gethash ',name *code*) ',body)
       (defun ,name ,args ,@ body)))

(defun* f ()
   (format nil "ok")
   (eval `(defun* f ()
             ,(list* '(format nil "added"))
                     (gethash 'f *code*)))))

Ну, тебе тут нужен свой дефан, да еще и явный евал. Впрочем, я не ниспровергатель CL, поэтому спорить не буду :)

Ну, тебе тут нужен свой дефан, да еще и явный евал.

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

Так, вроде, и в Си можно) Не думаю, что вопоос был про подобное.

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

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

Открою тебе секрет, eval всегда вызывается астоматом во время интерпретации, разница в том, что тебе в cl b других языках придется явно преобразовывать структуру в функцию, компилировать ее, а затем выполнять, а в рефлексивных языках никакой разницы между списком (или строкой) и функцией вообще нет. Функция, в данном случае, является просто списком. Всегда.

Все макросы гигиеничные, я правило понял?

Открою тебе секрет, eval всегда вызывается астоматом во время интерпретации, разница в том, что тебе в cl b других языках придется явно преобразовывать структуру в функцию, компилировать ее, а затем выполнять, а в рефлексивных языках никакой разницы между списком (или строкой) и функцией вообще нет. Функция, в данном случае, является просто списком. Всегда.

Это можно нахуячить десятистрочным макросом my-yoba-define.

Да ты не врубаешься, что ты сделаешь для частного случая, своего рода DSL, костыль. А в интерпретаторах это работает в общем случае. Сделать то о чем ты говоришь, можно в любом языке с поддержкой eval, тот же похапэ вэтом смысле, ничем не отличается от cl. Иными словами, через костыль можно имитировать, но это не значит, что оно есть. Пиши на CL Интерпретатор CL, тогда будет, да.

Да ты не врубаешься, что ты сделаешь для частного случая

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

При чем тут частный случай?

Псевдокод:

(special-define test1 <definition here...>)
(caual-define test2 <definition here...>)
(reflective-call test1 <args...>); ok
(reflective-call test2 <args...>); huy

Уж если на то пошло, Javascript тут имеет преимущество над CL, потому что там любую (обычную) функцию можно привести явно к строковому представлению.

Псевдокод:

Что-то у тебя неправильное. В реальности так:

...
...(rename-out [(my-yoba-define define) (ma-yoba-app #%app)])...
..,

#lang s-exp "my-yoba-module"
...

Костыль, язык в языке, что непонятно? Ты тогда все будешь вынужден определять через special-define, и забыть вообще о common lisp.

Зачем же все? Только то, что нужно. Нахуя мне определять через такой дифайн библиотечные ф-и, например? Мне их код нахуй не нужен. А вот если надо будет написать ф-ю чей код требуется перепидорасить - пожалуйста, все на месте.

Я тебе еще раз говорю, в любом языке с эвалом можно это сделать.

Я тебе еще раз говорю, в любом языке с эвалом можно это сделать.

РЕчь не о том что это можно сделать а о том, что это можно сделать _очень просто_. Если в языке Х нету некоторой фичи Y, но при этом ее можно сделать _очень просто_ - то можно считать, что такая фича есть. Потом что фичи нужны для того, чтобы ими можно было пользоваться. И если в общелиспе фичи нет, но на практике ей можно пользоваться так же просто как в ньюлиспе - то ну и что что ее нет?

То, что ты хочешь в компилируемом случае называется «самомодифицирующийся код», что в большинстве случаев, насколько мне известно, запрещено (по крайней мере под офтопиком) по причине безопасности.

Простые макросы - да.

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

ozkriff пишет:

Вот немного ссылок...

О, спасибо мил человек! А интерпретатор вроде есть, rusti называется и ещё какой то Rust-APL

Это не запрещено «по причинам безопасности», а это попросту невозможно технически, исключая случаи явного вызова вычислителя, поскольку никакого кода, годного для обработки и модификации target-языком в компилирующихся средах, в рантайме, попросту не существует. Ты просто не понимаешь программирования вообще. Ты пользователь языков, но ты не программист, не инженер. Просто зубрилко. Поэтому ты и ТО любишь, это религия, для вас, без нее вы не будете жрать свой хлеб.

Как же хреново быть тобой, всё таки, ты бы хоть немного подучился, прежде чем кукарекать.

call $+2
pop ebp
mov [ebp+6], сl
add eax, ebx

Что, так сразу и сольёшься, дебилушка? Или хоть что-нибудь скажешь в своё оправдание? Справедливости ради, не знаю как обстоит дело с хуками под 64-битной виндой, я что-то сейчас слабо представляю себе 9-байтное интро, для пяти-то байт лишний nop вставляли, а здесь уже без чуть более сложной техники с дизассемблером длин не обойтись.

на сишке

А ты, случаем, не попутал понятия модификация своего исходного кода в рантайме, с понятием модификация скомпилированного кода в рантайме?

Моя последняя попытка донести до тебя знания свет. Итак, как ты знаешь, у нас существует относительно однозначное представление ассемблерного кода в машинный и наоборот. Рассмотрим кусок программы, все адреса и опкоды реальны:

00401000     E8 00 00 00 00     call $+5
00401005     5D                 pop ebp
00401006     88 4D 04           mov [ebp+4], cl
00401009     01 D8              add eax, ebx

• Первая инструкция передаёт управление на адрес следующей инструкции, попутно занося этот же адрес в стек вызовов.
• Вторая инструкция вынимает этот адрес в регистр ebp, теперь мы знаем где мы, как код, расположены в памяти (в данном случае там будет 00401005)
• Третья инструкция перезаписывает первый байт по адресу что в ebp да плюс 4 (это будет 00401009, т.е. адрес последней инструкции) на содержимое регистра cl.

Если у нас в cl будет 01, то получаем инструкцию 01 D8 (add eax, ebx), то есть сложение, если там 29, то получаем инструкцию 29 D8 (sub eax, ebx), то есть вычитание, если 21, то 21 D8 (and eax, ebx), то есть битовое И, ну и так далее. И всё это происходит в рантайме, нам не нужно ничего перекомпилировать, нам не нужен никакой исходник, мы работаем напрямую с машинным кодом. Чаще всего такой фигнёй занимается вирусня и прочие не очень (или наоборот очень) полезные программы, на это дело часто остро реагируют антивирусы, а секция кода по умолчанию доступна только на чтение и исполнение.

Отладчики используют примерно такую же технику, но копаются уже в кишках других программ, они по мере продвижения по коду (step-by-step или по брекпоинтам) на месте тех самых точек останова тупо перезаписывают первый байт следующей инструкции на CC, превращая её в int 3, что при исполнении процессором генерирует исключение, которое уже и обрабатывается отладчиком, а там он показывает тебе состояние контекста и всего прочего. Вот как-то так в общих чертах.

А интерпретатор вроде есть, rusti называется и ещё какой то Rust-APL

rusti уже давно нет, да он и не был настоящим интерпретатором никогда.

По запросу «rust-apl» нашлось только https://github.com/AngryLawyer/rust-apl и последний коммит в нем 14 декабря 2013, так что оно вряд ли живое.

Ты показал модификацию машинного кода процессора на ходу выполнения. Но это не метапрограммирование.

Очень жаль, а вообще сложно делаются интерпретаторы компилируемых языков?

оффтопик: тут всегда так общаются? как будто на чат из доты2 смотришь...

игнорирование утверждений по причине несовременной терминологии.

а конкретно:

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

сам знаешь кто.

Есть диаметрально противоположное мнение

синт сахар приводит к раку точки с запятой.

Сам знаешь кто

алсо, см normal considered harmful

дык цитатка ответ на желание пометапрограммировать без должных (т.е. необходимых самой задачей) оснований.

кроме ии и прочей оптимизации исполнения шоб не итерпретировать для метопрограммирования в быту задач то мало.

Очень жаль, ...

Ну фиг знает, лично я жгучей необходимости в REPL не испытываю, это все-таки не лисп. Хотя, может, просто не привык работать с REPL и не понимаю, как бы он мне помог тут, если бы был.

... а вообще сложно делаются интерпретаторы компилируемых языков?

Тут не подскажу, я залезал только во внутренности интерпретаторов вроде lua`шного. С Ржавчиной, с виду, сложнее)). Вот, вроде, актуальная задача про repl - https://github.com/rust-lang/rust/issues/9898.

оффтопик: тут всегда так общаются? как будто на чат из доты2 смотришь...

Печально, но да. Просто игнорируй)

alex_public пишет:

смотря на все эти обзоры Rust'a я совсем не вижу метапрограммирования. Т.е. даже хотя бы такого как в C++ (в D оно ещё намного сильнее чем в плюсах). А это очень существенная часть языка, причём отлично сочетающаяся и нужная как раз в системных языках, т.к. она позволяет вносить в язык очень высокий абстракции при этом не добавляя ни капли оверхеда в рантайм

так что не только для ИИ

Давай задачу какую-нибудь рассмотрим. Именно задачу, а не «написать макрос/шаблон, который бы...». Т.е. что ты конкретно хочешь сделать.

в D есть mixin'ы