Re: Ядро Рефал


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


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

| On Fri, 2 Nov 2001, Arkady Klimov wrote:
|
| > Замечу только, что все, что до сих пор называлось "реализациями рефала" -
| > это были в том или ином смысле интерпретаторы (исполнители буквально),
| > то есть отладчики. Эффективная компиляция возникает только
| > как отображение после суперкомпилятора. И там (и только там) об удобствах
| > отладки речи уже не идет.
| Вот именно по этому и хочется иметь вычищенное ядро. Это позволит отделить
| компилятор от отладчика.
| >
| > | >
| > | > Ящики? Да без них рефал никто не станет использовать, хотя это и внешняя
| > | > по отношению к языку сущность. В рефале-6, на мой взгляд, они доведены до
| > | > некоторой завершенности. Суперкомпилятору они, конечно, мешают, но
| > | > объектно-ориентированная парадигма "мешает" куда больше, тем не менее
| > | > отбрасывать ее - значит уклоняться от решения проблем, которые ставит
| > | > сама жизнь.
| > | Кто-нибудь занимался анализом использования ящиков? Наверняка есть
| > | небольшое число ситуаций, в которых они полезны. И разработав методологию
| > | их обхождения можно обойтись и без ящиков. Здесь аналогия скорее не с ОО,
| > | а с GOTO. Когда-то казалось что без него ни как - пока Дейкстра не показал
| > | обратное.
| >
| > Если кто-то когда-то использовал "ящики" не по существу, - это еще не повод
| Не ясно какое их использование будет "по существу". Возможно то для чего
| нужны ящики проще запрограмировать на другом языке, а из него вызвать
| Рефал. Сам я на Рефале писал мало и мне ящики ни разу не понадобились.
| Задачи я выбирал простые и ориентированые на Рефал, и придумать случай в
| котором ящик уместен я не могу.

Одно из важных применений ящиков, где я не знаю, как обойтись без них - это
имитация "ленивости" = задержка + мемоизация. Вычисленные по первому
запросу значения затем помещаются в динамический, созданный заблаговременно,
ящик для последующих использований.

Кроме того, есть многие алгоритмы, которые в чисто функциональных терминах
выражаются просто плохо: топологическая сортировка, унификация, анализ ML-типов,
волновой метод поиска кратчайшего пути и т.п. Все это - разные частные случаи
инкрементного (=эффективного) вычисления неподвижной точки. Сейчас мы
предпочитаем программировать их императивно, то есть с переменными, или ящиками.
Когда-нибудь, наверно, и на эти задачи найдется свой Дейкстра, который научит нас делать
то же самое функционально (и столь же эфффективно). Не могу не вспомнить по этому
случаю "монотонные объекты" Андрея Климова. А для всяких экспериментов на эту тему
опять же нужны ящики.

| По моему анализ был бы очень полезен для развития языка.
Да, конечно.

| > для их изгнания из языка. Насчет GOTO тоже не все так просто. В результате
| > суперкомпиляции например, как и специализации, получаются существенно
| > "goto-ориентированные" программы, и еще неизвестно, во что нам обойдется
| > отсутствие GOTO в базовом языке их отображения (Яве).
| Для Явы ни кто не мешает порождать не текст на Яве, а сразу байт-код.
| Или еще какое-нибудь промежуточное представление. Получение Ява-текста
| ценно только своей наглядностью (в том числе и для инвесторов :-)).
Вот-вот. Кроме того, думаю, никто не станет использовать JScp, если не будет
иметь понятия о том, что у него на выходе.



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