Subject: Re: Ядро Рефал
From: Mike Potanin (potanin@mccme.ru)
Date: Fri Nov 02 2001 - 13:54:46 MSK
On Fri, 2 Nov 2001, Arkady Klimov wrote:
>
> Простота рефала обманчива: в его реализации приходится опираться
> на совершенно специфичиский "рантайм", включающий особую модель
> данных со своими механизмами сборки мусора и т.п. Понятия рефала уж
> очень оторваны от понятий архитектуры компьютера. Идея массивного
> представления выражений - важный шаг на пути сближения этих двух
> миров.
Представление строк - вопрос второстеменный. В Рефале+ пошли по пути
отделения представления от компилятора. Это создает возможность
использования специольного представления, оптимального для конкретной
задачи.
(Например возьмем биологию - для обработки какого-нибудь гена придется
работать со строками в несколько тысяч символов. В то же время операции
будут ограниченые - вставка/вырезание небольшой подстроки. И массивное и
списковое представление этого не вынесут. В тоже время можно сделать
строки, хорошо с этим работают. Например строка кодируется указателями на
начало и конец и строкой специальных точек, которые обозначают разрыв в
строке или вставку специального элемента - терма, спецсимвола или
ленивого вызова. Это позволит кодировать часто встречающиеся символы одним
байтом и сделает большинство операций дешевыми, но сделает невозможной
сборку мусора.
При желании можно поиграться с представлением служебной строки - например
сделать ее аналогичной основной (чем не метосистемный переход :-)), что
может быть позволит расширить область применения.)
>
> Аккуратный перехват ошибок и весьма осмысленная диагностика всегда
> считались ценнейшим качеством рефала, за которое, не в последнюю
> очередь, его и любили программисты. Типизации же в рефале просто нет,
> что тоже в некотором смысле ценность, и потому на run-time диагностику
> возлагаются задачи, обычно решаемые компиляторами при проверке типов.
> А программирование на рефале в стиле "не порождающих ошибки функций"
> будет только затруднять отладку.
Давайте разделять средства отладки и средства языка. Отладчик может себе
позволить сколь угодно неэффективное представление, лишь бы оно было
удобно для анализа. Отладчик - внешняя по отношению к языку сущьность, и
то что он (отладчик) умеет перехватывать ошибки языку знать не обязятельно
(а по моему даже не желательно).
>
> То, о чем пишет Кондратьев - возможность возбудить перехват
> с осмысленным дампом при зацикливании программы - тоже ценнейшая
> штука, к большому сожалению отстутвующая в большинстве реализаций
> рефала (о других языках и не говорю). А в нынешнем рефале-6 это не
> только диагностика, но и возможность вмешаться в процесс, продолжить
> его по тому или иному пути и т.п. И совсем это не дорого: при опросе
> "датчика" раз на 50-100 шагов замедление не превышает и 1%.
Может это все-таки оставить отладчику? Врядли кто захочит прервать
отлаженую программу, считающюю в течении месяца.
>
> Ящики? Да без них рефал никто не станет использовать, хотя это и внешняя
> по отношению к языку сущность. В рефале-6, на мой взгляд, они доведены до
> некоторой завершенности. Суперкомпилятору они, конечно, мешают, но
> объектно-ориентированная парадигма "мешает" куда больше, тем не менее
> отбрасывать ее - значит уклоняться от решения проблем, которые ставит
> сама жизнь.
Кто-нибудь занимался анализом использования ящиков? Наверняка есть
небольшое число ситуаций, в которых они полезны. И разработав методологию
их обхождения можно обойтись и без ящиков. Здесь аналогия скорее не с ОО,
а с GOTO. Когда-то казалось что без него ни как - пока Дейкстра не показал
обратное.
>
> Согласен, что ввод-вывод и прочие внешние операции спорно встраивать в сам язык.
> Но возможность вызывать рефал из чего-то другого здесь не лекарство, так как
> оставляет неудовлетворенной потребность вызывать ИЗ РЕФАЛА что-то другое.
> Наверно, правильнее был бы грамотный интерфейс по вызову из рефала функций
> написанных на других языках (Яве, например), и наоборот.
Да, было бы полезно разработать что то типа Haskellовского ffi. По моему в
Рефал+ этим тоже занимались.
>
> Аркадий.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD