Исправление quasimoto, (текущая версия) :
Пусть утверждение звучит так «в случае интерпетатора во время выполнения программы необходима доступность исполнителя, понимающего исходный язык программы».
Интерпретатор это и есть исполнитель понимающий исходный язык программы. Возможность заменить его предварительной компиляцией в другой язык который будет выполнять другой исполнитель это уже плюшки.
JIT по-факту интерпретатор байткода VM (JVM или LLVM).
Нет, сам по себе JIT это компилятор, а не интерпретатор. И когда я говорил JIT, я подразумевал рантайм компилятор в машинный код — в JVM и LLVM именно такой. JVM называют VM потому что там может отсутствовать JIT и VM будет интерпретировать/исполнять байткод, а в LLVM есть JIT и в этой части он вовсе не VM (хотя там EE вроде предоставляет возможность обычной интерпретации). Какого рода компилятором является JIT — из исходного кода или из байткода это уже зависит, в JVM это из байткода, в байткод компиляция ahead of time, в LLVM — из IR/биткода или средствами Clang+LLVM можно сделать прямо из исходного кода.
Это уже нарушение стандарта.
А вот в CL необходим именно компилятор или интерпретатор CL при выполнении программы.
Если хочется полноценной CL среды — конечно. Но не обязательно компилятор, может быть просто интерпретатор/VM, то есть как везде.
На GHC программа может его не использовать и тогда его в рантайме (в бинарнике) не будет. Это аналог system(«gcc ...») для Си или линковки с libgcc.
Да, хотя бы dlopen(3) & co.
Исходная версия quasimoto, :
Пусть утверждение звучит так «в случае интерпетатора во время выполнения программы необходима доступность исполнителя, понимающего исходный язык программы».
Интерпретатор это и есть исполнитель понимающий исходный язык программы. Возможность заменить его предварительной компиляцией в другой язык который будет выполнять другой исполнитель это уже плюшки.
JIT по-факту интерпретатор байткода VM (JVM или LLVM).
Нет, сам по себе JIT это компилятор, а не интерпретатор. И когда я говорил JIT, я подразумевал рантайм компилятор в машинный код — в JVM и LLVM именно такой. JVM называют VM потому что там может отсутствовать JIT и VM будет интерпретировать/исполнять байткод, а в LLVM есть JIT и в этой части он вовсе не VM (хотя там EE вроде предоставляет возможность обычный интерпретации). Какого рода компилятором является JIT — из исходного кода или из байткода это уже зависит, в JVM это из байткода, в байткод компиляция ahead of time, в LLVM — из IR/биткода или средствами Clang+LLVM можно сделать прямо из исходного кода.
Это уже нарушение стандарта.
А вот в CL необходим именно компилятор или интерпретатор CL при выполнении программы.
Если хочется полной CL среды — конечно. Но не обязательно компилятор, может быть просто интерпретатор/VM, то есть как везде.
На GHC программа может его не использовать и тогда его в рантайме (в бинарнике) не будет. Это аналог system(«gcc ...») для Си или линковки с libgcc.
Да, хотя бы dlopen(3) & co.