Re: Ядро Рефал


Subject: Re: Ядро Рефал
From: Arkady Klimov (klark@bagirra.net)
Date: Fri Nov 02 2001 - 14:17:33 MSK


----- Original Message -----
From: Mike Potanin <potanin@mccme.ru>
To: refal <refal@botik.ru>
Sent: Friday, November 02, 2001 1:54 PM
Subject: Re: Ядро Рефала

| On Fri, 2 Nov 2001, Arkady Klimov wrote:
|
| >
| > Простота рефала обманчива: в его реализации приходится опираться
| > на совершенно специфичиский "рантайм", включающий особую модель
| > данных со своими механизмами сборки мусора и т.п. Понятия рефала уж
| > очень оторваны от понятий архитектуры компьютера. Идея массивного
| > представления выражений - важный шаг на пути сближения этих двух
| > миров.
| Представление строк - вопрос второстеменный. В Рефале+ пошли по пути
| отделения представления от компилятора. Это создает возможность
| использования специольного представления, оптимального для конкретной
| задачи.
| (Например возьмем биологию - для обработки какого-нибудь гена придется
| работать со строками в несколько тысяч символов. В то же время операции
| будут ограниченые - вставка/вырезание небольшой подстроки. И массивное и
| списковое представление этого не вынесут. В тоже время можно сделать
| строки, хорошо с этим работают. Например строка кодируется указателями на
| начало и конец и строкой специальных точек, которые обозначают разрыв в
| строке или вставку специального элемента - терма, спецсимвола или
| ленивого вызова. Это позволит кодировать часто встречающиеся символы одним
| байтом и сделает большинство операций дешевыми, но сделает невозможной
| сборку мусора.
| При желании можно поиграться с представлением служебной строки - например
| сделать ее аналогичной основной (чем не метосистемный переход :-)), что
| может быть позволит расширить область применения.)
| >
| > Аккуратный перехват ошибок и весьма осмысленная диагностика всегда
| > считались ценнейшим качеством рефала, за которое, не в последнюю
| > очередь, его и любили программисты. Типизации же в рефале просто нет,
| > что тоже в некотором смысле ценность, и потому на run-time диагностику
| > возлагаются задачи, обычно решаемые компиляторами при проверке типов.
| > А программирование на рефале в стиле "не порождающих ошибки функций"
| > будет только затруднять отладку.
| Давайте разделять средства отладки и средства языка. Отладчик может себе
| позволить сколь угодно неэффективное представление, лишь бы оно было
| удобно для анализа. Отладчик - внешняя по отношению к языку сущьность, и
| то что он (отладчик) умеет перехватывать ошибки языку знать не обязятельно
| (а по моему даже не желательно).
| >
| > То, о чем пишет Кондратьев - возможность возбудить перехват
| > с осмысленным дампом при зацикливании программы - тоже ценнейшая
| > штука, к большому сожалению отстутвующая в большинстве реализаций
| > рефала (о других языках и не говорю). А в нынешнем рефале-6 это не
| > только диагностика, но и возможность вмешаться в процесс, продолжить
| > его по тому или иному пути и т.п. И совсем это не дорого: при опросе
| > "датчика" раз на 50-100 шагов замедление не превышает и 1%.
| Может это все-таки оставить отладчику? Врядли кто захочит прервать
| отлаженую программу, считающюю в течении месяца.

Замечу только, что все, что до сих пор называлось "реализациями рефала" -
это были в том или ином смысле интерпретаторы (исполнители буквально),
то есть отладчики. Эффективная компиляция возникает только
как отображение после суперкомпилятора. И там (и только там) об удобствах
отладки речи уже не идет.

| >
| > Ящики? Да без них рефал никто не станет использовать, хотя это и внешняя
| > по отношению к языку сущность. В рефале-6, на мой взгляд, они доведены до
| > некоторой завершенности. Суперкомпилятору они, конечно, мешают, но
| > объектно-ориентированная парадигма "мешает" куда больше, тем не менее
| > отбрасывать ее - значит уклоняться от решения проблем, которые ставит
| > сама жизнь.
| Кто-нибудь занимался анализом использования ящиков? Наверняка есть
| небольшое число ситуаций, в которых они полезны. И разработав методологию
| их обхождения можно обойтись и без ящиков. Здесь аналогия скорее не с ОО,
| а с GOTO. Когда-то казалось что без него ни как - пока Дейкстра не показал
| обратное.

Если кто-то когда-то использовал "ящики" не по существу, - это еще не повод
для их изгнания из языка. Насчет GOTO тоже не все так просто. В результате
суперкомпиляции например, как и специализации, получаются существенно
"goto-ориентированные" программы, и еще неизвестно, во что нам обойдется
отсутствие GOTO в базовом языке их отображения (Яве).

| >
| > Согласен, что ввод-вывод и прочие внешние операции спорно встраивать в сам язык.
| > Но возможность вызывать рефал из чего-то другого здесь не лекарство, так как
| > оставляет неудовлетворенной потребность вызывать ИЗ РЕФАЛА что-то другое.
| > Наверно, правильнее был бы грамотный интерфейс по вызову из рефала функций
| > написанных на других языках (Яве, например), и наоборот.
| Да, было бы полезно разработать что то типа Haskellовского ffi. По моему в
| Рефал+ этим тоже занимались.
| >
| > Аркадий.



This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD