Subject: Re: Ядро Рефал
From: Mike Potanin (potanin@mccme.ru)
Date: Fri Nov 02 2001 - 15:24:08 MSK
On Fri, 2 Nov 2001, Arkady Klimov wrote:
> | > Если кто-то когда-то использовал "ящики" не по существу, - это еще не повод
> | Не ясно какое их использование будет "по существу". Возможно то для чего
> | нужны ящики проще запрограмировать на другом языке, а из него вызвать
> | Рефал. Сам я на Рефале писал мало и мне ящики ни разу не понадобились.
> | Задачи я выбирал простые и ориентированые на Рефал, и придумать случай в
> | котором ящик уместен я не могу.
>
> Одно из важных применений ящиков, где я не знаю, как обойтись без них - это
> имитация "ленивости" = задержка + мемоизация. Вычисленные по первому
> запросу значения затем помещаются в динамический, созданный заблаговременно,
> ящик для последующих использований.
Ленивость я давно предлагою ввести в язык (в моей haskellной реализации
была ленивость термов и правого хвоста, для более сложной надо придумывать
сложное представление строк). Мемоизация тоже там к месту - при
программировании в функциональном стиле на семантику она не влияет, а
эффективность может поднять.
>
> Кроме того, есть многие алгоритмы, которые в чисто функциональных терминах
> выражаются просто плохо: топологическая сортировка, унификация, анализ ML-типов,
> волновой метод поиска кратчайшего пути и т.п. Все это - разные частные случаи
> инкрементного (=эффективного) вычисления неподвижной точки. Сейчас мы
> предпочитаем программировать их императивно, то есть с переменными, или ящиками.
> Когда-нибудь, наверно, и на эти задачи найдется свой Дейкстра, который научит нас делать
> то же самое функционально (и столь же эфффективно). Не могу не вспомнить по этому
> случаю "монотонные объекты" Андрея Климова. А для всяких экспериментов на эту тему
> опять же нужны ящики.
А эти задачи адекватны языку? Может в каких-то случаях удобнее для них
иметь библиотеку написанную на C/C++?
К тому же итерации легко програмировать через остаточную рекурсию, которая
реализуется эффективно. Мне кажется что многое к ней сведется - хотя надо
еще подумать.
>
> | По моему анализ был бы очень полезен для развития языка.
> Да, конечно.
>
> | > для их изгнания из языка. Насчет GOTO тоже не все так просто. В результате
> | > суперкомпиляции например, как и специализации, получаются существенно
> | > "goto-ориентированные" программы, и еще неизвестно, во что нам обойдется
> | > отсутствие GOTO в базовом языке их отображения (Яве).
> | Для Явы ни кто не мешает порождать не текст на Яве, а сразу байт-код.
> | Или еще какое-нибудь промежуточное представление. Получение Ява-текста
> | ценно только своей наглядностью (в том числе и для инвесторов :-)).
> Вот-вот. Кроме того, думаю, никто не станет использовать JScp, если не будет
> иметь понятия о том, что у него на выходе.
Можно расширить язык этим goto и написать компилятор (с открытыми
исходниками). И волки сыты и овцы целы.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD