Re: Re[2]: portable GUI

From

Shura Zam ()

To

Boris Rudakov ()

Date

2003-07-28T14:21:34Z

Area

CARBON.COPY

 * Forwarded from area 'SU.WINDOWS.PROG'
From: "Shura Zam" <nagual@promsoft.ru>

>  SZ> Предлагаю следующее определение:
>  SZ> Язык является необходимо интерпретируемым если
>  SZ> в нём сушествует оператор/функция которая принимает строку,
>  SZ> и выполняет её по правилам языка.
>
> Нет, не принимается :)
> Такое определение не имеет вообще ничего общего с общепринятым :)
>
> "Интерпретация" - это когда инструкции программы являются не native
> инструкциями некоторой аппаратры (железяки), а требуют для своего
исполнения
> другой программы - интерпретатора, которая исполняет эти инструкции. Это
> определение является общепринятым.
Ты же сам понимаешь, что в современной системе довольно много уровней
и однозначно сказать что исполняется аппаратурой, а что интерпретируется
достаточно трудно. Даже если не принимать во внимание разнообразные
think-и (почти все GUI-ёвые либы под win на С++) и jit-ы.
Тот же printf интерпретируется свои аргументы, хотя можно представить
себе компилятор, который бы в некоторых случаях сразу бы генерил
нужный код.

В обшем я с этой концепцией согласен, хотя повторюсь, сейчас она
выглядит слишком упрощенной, и в конечном итоге вписывается в
"модульность", и/или "слоёность" ;-в

>  SZ> Т.е. интерпретатор языка должен входить и быть доступен в системе
>  SZ> выполнения.
>
> О ! Значит если я залезу в zend_exceute.c и закомментарю обработку
инструкции
> eval(), то ПХП станет компиллятором ?!?!?!?!
Нет, не станет.
Но он _перестанет_ быть PHP, так же как и Python перестанет
быть Python, и Perl перестанет быть Perl.
Во всех перечисленных выше языках можно выделить
"компилируемое" подмножество, множество программ для этого
подмножества _существенно_ меньше чем всё множество допустимых
программ для языка. ;-в
Простой пример: убери из компилятора C++ обработку 1го ключевого слова
(например virtual) - можно ли это будет называть компилятором с C++ ? ;-в

> Виш ли, наличие рекурсивного доступа к парсеру / интерпретатору из
> интерпретируемой программы - добрая воля авторов этого интертрепатора и не
> более того.
Попровуй убрать функции eval & applay из Lisp и посмотри что у тебя
останится. ;-в

>  SZ> По этому определению Java не является необходимо интерпретируемым
>  SZ> языком.
>
> Даже если принять твою абсурдную классификацию, то Жаба - интерпретатор.
> Ты никогда не слышал про такие вещи как
>
> * ClassLoader.defineClass(byte[] b, int off, int len);
> * JNI's JNIEnv->DefineClass(const char *name, jobject loader, const jbyte
*buf,
>    jsize len);
>
> * Package sun.tools.javac
> * Class.forName(String className);
>
> Ы ?
Это _не_ сервис _языка_, это сервис среды окружения.
Что ты будешь делать с этим кодом если у тебя не доступен пакет sun?
Зная интерфйс к компилятор и умея его вызывать подобное пишется на
любых языках. Например, очень нетрудно заюзать GCC или comp32p.dll
от Билдера. Но то этого _язык_ не меняется.

>  SZ> Так же как и Basic.
> Лет 5-6 назад Мелкософт официально заявлял что НЕ БУДЕТ делать КОМПИЛЛЯТОР
> с VB, потому как это с их точки зрения некошерно, хотя технически - плевое
> дело.
> Мнда, знали бы они до какой степени они не владеют правильной
> терминологией :):):)
VB6 умеет компилить в p-cod и в nativ.
Но, если посмотреть что лежит в этом nativ то трудно назвать это честным
nativ. ;-в
Псевдокодом можно это написать так:
goto start
byte Code[] ="............";
start: EvalCode(Code)
Причём многие обработчики событий представляют честные инструкции
процессору.

>  SZ> А вот Perl, Python, Lisp JavaScript - являются.
> И чтобы сделать их компилляторами мне достаточно заблокировать в них вызов
> функции парсинга ?! Гы-гы-гы :):):)
Чтобы выделить "компилируемое" подмножество.
А написать кодогенератор для такого подмножества, если есть
исходный парсер - дело техники.

> Наличие же или отсутсвие возможности вызвать из интепретируемой программы
> парсер этого же интерпретатора - к вопросу вообще никак никаким боком не
> относится. Это - феня интерпретатора (исполняющей системы) и ничего более.
> Захотели - сделали, не захотели (или из соображений секьюрити не
> изволили) - не сделали.
Я думаю, что при проектировании/создании языка надо учитывать
наличие/отсутствие этой "фени".
Например, убери её из Perl, и ты лишишся возможности например обработать
due в подпрограмме. Стало быть многие скрипты/библиотеки/комплексы
перестанут работать. Т.е. используя такое подмножество,ты используешь
совершенно другой язык и вынужден использовать другой дизайн.



--- ifmail v.2.15dev5
 * Origin: Golden Telecom (2:5020/400)