Subject: Re: Ядро Рефал
From: Mike Potanin (potanin@mccme.ru)
Date: Mon Nov 05 2001 - 14:51:49 MSK
On Sat, 3 Nov 2001, Anton Yu. Orlov wrote:
> Имеются в виду проблемы с переносимостью с одного диалекта на
> другой? Но ведь именно с целью решения этих проблем и был
Не только. Здесь уже обсуждались сложности сборки Рефала 6 на Linux.
У меня были трудности с Рефал+ на FreeBSD. И объщее в этих проблемах было
то, что при обработке ошибок транслятор пользовался системно-зависимыми
вещами. В Рефал+ например в конструкции языка $trap перехватывается ошибка
ввода/вывода, хотя она по идее должна относится к библиотеке и язык про
нее знать не должен. Подобная связяность не способствует переносимости.
В частности по этому хочется иметь просто реализуемое ядро (хорошо бы,
описаное в рамках AS).
> разработан абстрактный синтаксис (AS), в который легко
> компилируются все современные варианты Рефала. Уже давно Андреем
> Слепухиным написан такой компилятор для Рефала+. С компиляцией в
> AS Рефала-5 вообще нет никаких проблем (ну, разве что повышатель
> арности было бы неплохо иметь :), с Рефалом-6 чуть сложнее
> (скажется разница с Рефалом+ в семантике знака "=", возможно, ещё
> какие-то тонкости), но это тоже должно делаться достаточно
> прямолинейно.
>
> Соответственно предполагается, что отныне все реализации будут
> работать именно с AS - человеку достаточно один раз написать
> программу на любимом диалекте Рефала, после чего он будет иметь
> возможность запустить её на разных рантаймах: списочном,
> векторном, ленивом с мемоизацией, параллельном...
> Абстрактный синтаксис (правда, без комментариев) можно посмотреть
> здесь: http://glade.nmd.msu.ru/~pooh/abstract_syntax.txt
>
> А вот смысла в выделении ядра, которое поддерживалось бы
> суперкомпилятором я не вижу. Каким суперкомпилятором?
> Суперкомпиляторов Рефала уже было не мало, и хочется надеяться,
> что их число будет увеличиваться ;-). И в каждом конкретном
> случае автору суперкомпилятора, конечно, видней над каким именно
> подмножеством Рефала работать. Т.е. автор может сказать, что
> программы на таком подмножестве (ядре) будут данным
> суперкомпилятором отлично обрабатываться, на более широком
> подмножестве не ждите блестящих результатов, а с полным AS данный
> суперкомпилятор, к примеру, вообще не работает. На мой взгляд, не
> стоит выкидывать из языка какие бы то ни было конструкции,
> руководствуясь тем, что это мол никакой суперкомпилятор никогда
> не съест. Ведь теория развивается...
Будем ждать и надеятся :-). Только обидно что scp4 не самоприменим....
>
> > Ленивость я давно предлагою ввести в язык (в моей haskellной реализации
> > была ленивость термов и правого хвоста, для более сложной надо придумывать
> > сложное представление строк). Мемоизация тоже там к месту - при
> > программировании в функциональном стиле на семантику она не влияет, а
> > эффективность может поднять.
>
> Точно также, как и посадить, вплоть до полной неработоспособности
> программы. Уверен, что для любого способа мемоизации, намертво
> заделанного в реализацию, найдётся задача, которая без этой
> мемоизации работала бы на порядок быстрее. Возьмём, к примеру,
Уточню что я хотел сказать. Ленивость и мемоизация "почти" не меняет
семантики. По этому значительную часть операций с программой (вплодь до
суперкомпиляции) в принципе можно было бы производить ни чего не зная про
эти особенности реализации. Если реализовывать мемоизацию через ящики, то
суперкомпилятору придется не сладко. И не зависимо от развития теории -
программу без побочных эфектов всегда анализировать будет легче.
По этому и хочется очистить код от не относящемуся к сути программы.
Принципиальных проблем я в этом не вижу.
> те же гены - надо работать с выражением огромной длины,
> итеративно изменяя его небольшие куски. Если мы будем
> запоминать всё это выражение после очередной операции, то на
> поддержание списка мемоизированных значений мы угрохаем огромное
> время и очень быстро - всю имеющуюся в наличии память. А при
> заданном наперёд способе мемоизации такое всегда можно
> организовать ;-). Однако, если нет ящиков, то подобная задача
> всё-равно скорей всего окажется не под силу существующим
> рантаймам, хотя они и не ленивы и в них нет встроенной
> мемоизации. Поэтому придётся либо действительно писать рантайм
> спецефически под эту задачу, либо использовать библиотеку на
> C/C++, либо вообще писать на более подходящем языке, чем Рефал.
> Но при наличии ящиков можно легко организовать и своё собственное
> представление выражений и работу с ними, и соответствующую задаче
> мемоизацию. А при наличии в Рефале инструментов, позволяющих
Можно конечно поддерживать 2 версии библиотек - эффективную и
эффективно суперкомпилируемую (как сейчас делается для Java).
Но хорошо бы иметь средство эту задачу упрощающее, типа аннотации
программы, что эта функция предпологается мемоизованной, а эта ленивой.
При этом реализацию мемоизации и ленивости от самих функций отделить.
> решать задачу с приемлемой эффективностью, меня в сторону С, а
> тем более С++ и силком не затащишь ;-). Ящики - это необходимый
> инструмент при решении задач, где требуется использовать данные,
> для которых рантайм не даёт эффективного представления. Ведь не
> писать же под каждую задачу свой рантайм. Конечно, интерфейс с
> другими языками программирования (С/С++ в первую очередь) - ещё
> более гибкий инструмент и он, безусловно, нужен. В принципе,
> можно и ящики считать просто внешней библиотекой, равноправной с
> теми, которые может написать пользователь. Но на мой взгляд, то
> что они входят именно в Рефал имеет большой плюс: всякие
> программы-метавычислители могут понимать, что имеют дело именно с
> ящиками, а не с произвольными внешними вызовами, и действовать,
> исходя из свойств ящиков. Простейшее, что приходит в голову:
> программу, использующую только явно указанные ссылки на
> глобальные ящики, можно скомпилировать в аналогичную программу
> без ящиков ;-).
Интересна более общая задача - с библиотекой связывать описание ее свойств
для метавычислителя. Тогда и ящики, и арифменику можно было бы вынести в
библиотеку.
>
> Антон.
>
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD