Subject: Re: Ядро Рефал
From: Anton Yu. Orlov (orlov@mccme.ru)
Date: Sat Nov 03 2001 - 01:45:34 MSK
Добрый вечер, всем!
On Fri, Nov 02, 2001 at 12:03:00 +0300, Mike Potanin wrote:
>
> Рефал по сути язык очень просто, но конкретные реализации
> навешивают на него столько, что возникают проблемы, например с
> переносимостью. По моему стоит обсудить ядро языка, которое по
> первых легко реализовывалось (с точностью до представления
> строк), во вторых поддерживалось бы суперкомпилятором.
> Остальное попытаться вынести в библиотеки или вообще выкинуть.
Имеются в виду проблемы с переносимостью с одного диалекта на
другой? Но ведь именно с целью решения этих проблем и был
разработан абстрактный синтаксис (AS), в который легко
компилируются все современные варианты Рефала. Уже давно Андреем
Слепухиным написан такой компилятор для Рефала+. С компиляцией в
AS Рефала-5 вообще нет никаких проблем (ну, разве что повышатель
арности было бы неплохо иметь :), с Рефалом-6 чуть сложнее
(скажется разница с Рефалом+ в семантике знака "=", возможно, ещё
какие-то тонкости), но это тоже должно делаться достаточно
прямолинейно.
Соответственно предполагается, что отныне все реализации будут
работать именно с AS - человеку достаточно один раз написать
программу на любимом диалекте Рефала, после чего он будет иметь
возможность запустить её на разных рантаймах: списочном,
векторном, ленивом с мемоизацией, параллельном...
Абстрактный синтаксис (правда, без комментариев) можно посмотреть
здесь: http://glade.nmd.msu.ru/~pooh/abstract_syntax.txt
А вот смысла в выделении ядра, которое поддерживалось бы
суперкомпилятором я не вижу. Каким суперкомпилятором?
Суперкомпиляторов Рефала уже было не мало, и хочется надеяться,
что их число будет увеличиваться ;-). И в каждом конкретном
случае автору суперкомпилятора, конечно, видней над каким именно
подмножеством Рефала работать. Т.е. автор может сказать, что
программы на таком подмножестве (ядре) будут данным
суперкомпилятором отлично обрабатываться, на более широком
подмножестве не ждите блестящих результатов, а с полным AS данный
суперкомпилятор, к примеру, вообще не работает. На мой взгляд, не
стоит выкидывать из языка какие бы то ни было конструкции,
руководствуясь тем, что это мол никакой суперкомпилятор никогда
не съест. Ведь теория развивается...
On Fri, Nov 02, 2001 at 15:24:08 +0300, Mike Potanin wrote:
> On Fri, 2 Nov 2001, Arkady Klimov wrote:
>
> > | > Если кто-то когда-то использовал "ящики" не по существу, - это еще не повод
> > | Не ясно какое их использование будет "по существу". Возможно то для чего
> > | нужны ящики проще запрограмировать на другом языке, а из него вызвать
> > | Рефал. Сам я на Рефале писал мало и мне ящики ни разу не понадобились.
> > | Задачи я выбирал простые и ориентированые на Рефал, и придумать случай в
> > | котором ящик уместен я не могу.
> >
> > Одно из важных применений ящиков, где я не знаю, как обойтись без них - это
> > имитация "ленивости" = задержка + мемоизация. Вычисленные по первому
> > запросу значения затем помещаются в динамический, созданный заблаговременно,
> > ящик для последующих использований.
> Ленивость я давно предлагою ввести в язык (в моей haskellной реализации
> была ленивость термов и правого хвоста, для более сложной надо придумывать
> сложное представление строк). Мемоизация тоже там к месту - при
> программировании в функциональном стиле на семантику она не влияет, а
> эффективность может поднять.
Точно также, как и посадить, вплоть до полной неработоспособности
программы. Уверен, что для любого способа мемоизации, намертво
заделанного в реализацию, найдётся задача, которая без этой
мемоизации работала бы на порядок быстрее. Возьмём, к примеру,
те же гены - надо работать с выражением огромной длины,
итеративно изменяя его небольшие куски. Если мы будем
запоминать всё это выражение после очередной операции, то на
поддержание списка мемоизированных значений мы угрохаем огромное
время и очень быстро - всю имеющуюся в наличии память. А при
заданном наперёд способе мемоизации такое всегда можно
организовать ;-). Однако, если нет ящиков, то подобная задача
всё-равно скорей всего окажется не под силу существующим
рантаймам, хотя они и не ленивы и в них нет встроенной
мемоизации. Поэтому придётся либо действительно писать рантайм
спецефически под эту задачу, либо использовать библиотеку на
C/C++, либо вообще писать на более подходящем языке, чем Рефал.
Но при наличии ящиков можно легко организовать и своё собственное
представление выражений и работу с ними, и соответствующую задаче
мемоизацию. А при наличии в Рефале инструментов, позволяющих
решать задачу с приемлемой эффективностью, меня в сторону С, а
тем более С++ и силком не затащишь ;-). Ящики - это необходимый
инструмент при решении задач, где требуется использовать данные,
для которых рантайм не даёт эффективного представления. Ведь не
писать же под каждую задачу свой рантайм. Конечно, интерфейс с
другими языками программирования (С/С++ в первую очередь) - ещё
более гибкий инструмент и он, безусловно, нужен. В принципе,
можно и ящики считать просто внешней библиотекой, равноправной с
теми, которые может написать пользователь. Но на мой взгляд, то
что они входят именно в Рефал имеет большой плюс: всякие
программы-метавычислители могут понимать, что имеют дело именно с
ящиками, а не с произвольными внешними вызовами, и действовать,
исходя из свойств ящиков. Простейшее, что приходит в голову:
программу, использующую только явно указанные ссылки на
глобальные ящики, можно скомпилировать в аналогичную программу
без ящиков ;-).
Антон.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD