Subject: Re: Refal -> Java? РефалАС-->АСАИЯ
From: Arkady Klimov (klark@bagirra.rinet.ru)
Date: Fri Dec 10 1999 - 17:43:22 MSK
Добрый день,
спасибо, Сергей, Андрей, Коля и все кто еще откликнется.
Конечно, идея не новая, и более того, не окончательная. Как
показывает обсуждение, тут еще возможно богатство вариантов.
Однако, я хотел бы отметить один дополнителный принцип, который как мне
кажется, может нас благотворно ограничить. Он высказан Колей и тут я
целиком его поддерживаю:
" Язык и библиотека встроенных функций должны выглядеть
" максимально естественно с точки зрения Явы.
" Можно высказать еще более сильное пожелание:
" хотелось бы, чтобы рефал был интегрирован в Яву.
Я тоже держал в уме что-то подобное, когда подбирал вариант для
представления данных и функций. Скажу больше: хотелось бы, чтобы из рефала
было бы легко вызвать ЛЮБОЙ метод Явской библиотеки, в том числе еще не
написанный. И для этого, мне кажется, есть все предпосылки, не последняя из
которых - Явское понятие о reflection. (С другой стороны неизбежно, что
структура рефал-выражения, его образ в Яву будет лишь частью возможных
структур Явы. Есть тут соблазн свести различие к минимуму так: считать, что
выражение в скобках - это массив типа Object. Но я не уверен, что это будет
хорошо и в других отношениях.)
Но так или иначе принцип максимальной естественности вложения в Яву - это
первое, чем надо руководствоваться при принятии подобных решений.
----- Original Message -----
From: Andrey Slepuhin <pooh@msu.ru>
To: Sergei M. Abramov <abram@botik.ru>
Cc: Arkady Klimov <klark@bagirra.rinet.ru>; Andrei Klimov
<klimov@keldysh.ru>; refal ; <refal@botik.ru>; Lyuda Solovskaya
<socol@ispras.ru>; Mikhail Kovtun <mkovtun@nortelnetworks.com>
Sent: Friday, December 10, 1999 2:56 PM
Subject: Re: Refal -> Java? РефалАС-->АСАИЯ !
> > "Sergei M. Abramov" wrote:
> >
> > День добрый, всем!
> >
> > Позвольте краткую реплику, по поводу:
> >
> > Date: 7 декабря 1999 г. 22:45
> > Subject: Refal -> Java
> >
> > ================
> > (0) Блестящая идея!
> > ================
> >
> > Идея компилировать Рефал(ы) в императивный язык (функция-->в функцию,
> > развилки-->в "IF", вызовы-->в CALL, циклы--в циклы) как убедительно
> > показал Алик, достояна самого пристального внимания...
> >
> > Я давно (с лета!) не испытывал такого Рефал-удовлетворения и
> > Рефал-подъема!
> >
> > ===================
> > (1) Давно забытое старое
> > ===================
> >
> > Конечно, идея старая. И даже был ведь компилятор Рефала Плюс в Си.
> >
> > Правда, идея Алика--намного глубше ТОГО компилятора--там был все-таки
> > виртуальный код.
> >
> > Основная мысль у Алика (и именно ее надо не потерять), в том, что:
> > виртуальный код НЕ НУЖЕН, ОН ТОЛЬКО МЕШАЕТ (!!!).
Арк:
Да, я также это имел в виду. Беда с виртуальным кодом (тем, на котором
работает нынешний релиз Рефала Плюс) - что он раскладывает функцию в
достаточно (то есть слишком) мелкие операции, существенно опирающиеся на
стек, что весьма затрудняет переход к другим моделям отображения и
выполнения. Нет, это по-прежнему возможно, но больше будет похоже на
мазохизм, поскольку придется проделать в сущности обратный переход к
исходным понятиям рефала - образцам, выражениями и т.п.
>
> Ну вот...
>
> >
> > Нужна прямая синтаксическая компиляция из АС в императивный язык (и
> > Ява тут не причем):
> >
> > 1 функция-->в функцию;
> > арность-->в арность;
> > коарность-->хотелось бы в коарность, (но можно выкрутиться и
> > массивом, хотя надо честно себе сказать--это именно "выкрутиться",
> > кривое решение, по хорошему надо возвращать раздельно).
>
> Если хочется сделать коарность, то зачем изобретать велосипед -
> функция (a, b) <- f (x, y, z) представляется как:
>
> C:
> объявление:
> res_t f (const obj_t, const obj_t, const obj_t, obj_t*, obj_t*) ;
> вызов:
> res = f(x,y,z,&a,&b);
> C++:
> объявление:
> res_t f (const obj_t, const obj_t, const obj_t, obj_t&, obj_t&);
> вызов:
> res = f(x,y,z,a,b);
> Java:
> объявление:
> Res f (Obj, Obj, Obj, ObjHolder, ObjHolder);
> вызов:
> ObjHolder _a=new ObjHolder();
> ObjHolder _b=new ObjHolder();
> res = f(x,y,z,_a,_b);
> a=_a.value; b=_b.value;
>
> В результат при этом помещается fail и может быть еще какакя-нибудь
> необходимая информация.
> Это вполне стандартное представление коарности (см. передачу out и inout
> параметров в IDL-mapping'е для соответствующих языков - чай не дураки
> все-таки делали);
Арк:
В решении этого вопроса я поддерживаю мысль, что не надо изобретать
велосипед:
надо выбирать из уже изобретенных. Но их тоже несколько.
Многое еще зависит от целей, от контекста. Насколько я понимаю,
у них там в IDL есть такое понятие - out и inout параметр, их-то они так и
отображают.
А еще в том же IDL есть понятие результата, значения функции - и его
отображают результатом же функции на С или метода Явы.
Я также видел, что использования массива для выдачи нескольких
(фиксированного числа, порядка 3) результатов-объектов,
является достаточно распространенной практикой на Яве.
В любом случае полезно соблюдать следующие принципы:
1. Если результат один, то он и результат (а не out-параметр),
2. Если результатов несколько - должно быть формальное правило для
однозначного определения сигнатуры на Яве.
3. Также желательно, чтобы существовало обратное правило - по сигнануте на
Яве перейти к формату.
А клоню я на самом деле к тому, что идея использовать переменные для
результатов мне не очень нравится.
Но будем размышлять дальше, имея в виду и такую возможность.
>
> >
> > 2 переменные-->в переменные;
>
> На самом деле, с точки зрения эффективности - не факт, что такая
> реализация будет работать быстрее, чем стековая - это можно будет
> проверить только на практике. Да и в других отношениях стековая
> реализация может оказаться удобнее - впрочем, это не утверждение,
> а скорей раздумья на тему... :-)
Арк:Размышлять надо!
>
> > 3 развилки-->в "IF";
>
> Вот в этом я совсем не уверен. С точки зрения компиляции в Java
> развилки в общем случае будут выглядеть примерно так:
Арк:
А это и есть IF, в сочетании с break, continue и метками. Примерно такое
я и имел в виду. Ограничение Явы состоит в том, что в ней нет goto. Но есть
break (и continue) с меткой блока - многоуровневый выход.
Из теории известно, что этого достаточно
для имитации любых goto (без введения переменных состояния).
Но для рефала и не нужны любые. А возвраты, удлинения достаточно хорошо
ложатся на структуры из блоков и циклов.
>
> alt_label: { // начало развилки
> alt1: { // первая альтернатива
> ...
> if ([FAIL]) break;
> ...
> [ хвост после = ]
> ...
> if ([FAIL]) break alt_label; // а если блок непрозрачный, то можно и
> глобально
> // пофэйлиться
> ...
> break alt_label;
> }
> alt2: { // вторая альтернатива
> ...
> break alt_label;
> }
> ...
> [FAIL]
> }
>
> >
> > 4 вызовы-->в CALL;
>
> Только вот, боюсь, в Java будут проблемы с хвостовой рекурсией.
> Я пока не вижу, как с ней бороться. Как это делать в C/C++ я
> могу представить (правда, для стековой реализации, когда все функции
> имеют
> один прототип).
Арк:
Это действительно будет проблемой. Но я считаю, что из этого не стоит
делать проблему.
Пусть в первой реализации все вызовы будут стековыми. Потом будем
оптимизировать, хотя бы иногда, в наиболее очевидных случаях.
Я могу представить себе вариант компилятора, который выявляет классы
взаимно-рекурсивных функций, строит обобщенный формат для них и
для всех генерит один общий Ява-метод, в котором хвостовой вызов замещается
переходом на начало; а для каждой функции - также отдельный метод
со своим форматом для входа извне.
>
> > 5 циклы--в циклы (хочу в императивном языке иметь метки и GOTO
> > внутри тела функции! Не знаю, в Яве-то они есть?);
>
> goto в Java нету, но без них можно обойтись.
>
> >
> > 6 "::" в присваивания;
> >
> > 7 ":" в цепочку конструкций, с широкой эксплуатацией преимуществ
> > массивного представления списков:
> > (а) прямое обращение к термам по индексу;
> > (б) проверка длинны массива, прежде чегм ковыраться в термах.
> >
> > Ради исторической справедливости скажу, что даже в такой формулировке
> > (1--7) идея у нас была уже давно. А именно,
> >
> > * я четко помню, что Рутик и СеРгей обсуждали такую компиляция
> > (по крайней мере, раздел "2. переменные-->в переменные;" мне помнится
> > четко);
> >
> > * и в своих играх в НИЦЭВТе (Рефал-->ПЛ/1-МДА) я выписывал (но
> > не реализовал!) использование "7.б Проверка длинны массива, прежде
> > чегм ковыраться в термах";
> >
> > * а в понедельник идя из МГУ в метро (за день !!!, когда я от
> > Алика узнал о его письме!) с Андреем Слепухиным мы именно такую
> > реализацию обсуждали ;-)
> >
> > Сказанное выше не умалаяет исторического значения сделанного Аликом
> > шага--надо было не просто обсуждать, надо было вспомнить это самое
> > "давно забытое старое" и не побояться ярко показать, что оно красиво и
> > НАСТОЛЬКО эффективно (надо было попрограммировать и замерить
> > эффективность!)
> >
> > СПАСИБО!
> >
> > =============================
> > (2) Надо делать быстро и качественно
> > =============================
> >
> > Это общий мотив всех откликов на Аликино письмо. И я присоединяююсь к
> > этому.
> >
> > Ну так и давайте от общих слов попробуем перейти к конкретному
> > обсуждению (прежде чем перейти к делу ;-). Тем более (по результатом
> > восторженной реакции и после локального обсуждения со Светланой
> > Пономаревой) кажется могут быть волонтиры, которые возможно до 15
> > января будут иметь "дырку" для написания такого компилятора.
> > Сложного-то в нем ничего ведь нету!
> >
> > Так что значит "делать быстро и качественно" (чтобы по возможности
> > потом не переделывать)? Мне кажется, это осначает:
> >
> > * Компилировать надо из АС
>
> Для этого надо AS довести до стабильного состояния. С моей точки зрения
> -
> это не больше пары часов совместного обсуждения при очной встрече
> всех заинтересованных лиц. При обсуждении по почте может и неделя уйти.
>
> > * А при чем тут Ява? Компилировать надо в АСАИЯ (в Абстрактный
> > Синтаксис Абстрактного Императивного Языка)
Арк:
Насчет гипотетического АСАИЯ:
1. Осмелюсь предположить, что из всех упомянутых языков (С, PL, T, Java),
Java окажется ближе всего к этому АСАИЯ.
2. Но я согласен, что все равно полезно отрезать какие-то лишние детали Явы
и несколько "поднять" уровень операций, используемых при отображении
рефала.
3. Важно найти хорошую точку, где могут быть слиты в один язык как Рефал,
так и язык графов суперкомпилятора SCP-4. Может это и будет АСАИЯ. АНдрей,
предоставьте нам пожалуйста, материалы на эту тему.
>
> Только вот боюсь, такой синтаксис будет зафиксировать сложнее, чем
> рефальский.
>
> > =======================
> > (3) Компилировать надо из АС
> > =======================
> >
> > Думаю, с этим тезисом все согласятся.
>
> Я не согласен :-)). Это что же, я зря выдачу VC делал? :-[
> И никто меня не остановил...
>
> > Тем самым, после выступления Алика можно сделать два адмнистративных
> > заявления:
> >
> > -а- работа в направлении "уметь выдавать виртуальный код из
> > РефалПлюс компилятора"--имеет низкий приоритет, так как для
> > промышленной реализации Аликовой идеи:
> > >...виртуальный код НЕ НУЖЕН, ОН ТОЛЬКО МЕШАЕТ (!!!)
> >
> > -б- работа в направлении "уметь выдавать АС из РефалПлюс
> > компилятора"--имеет ВЫСОКИЙ приоритет.
> >
> > ========================
> > (4) А при чем тут Ява?
> > Компилировать надо в АСАИЯ
> > ========================
> >
> > Объяснюсь. Ставя задачу именно так "компилировать надо в АСАИЯ" мы
> > легко получаем:
> >
> > -1- не только компилятор Рефал в Яву (я согласен, он весьма
> > интересен!) но и компиляторы Рефал->Си/Си++, и Рефал->Т-язык (пардон
> > за шкурный интерес ;-);
>
> Я боюсь, что C, C++ и Java - слишком разные (!) языки, и чтобы хорошо
> компилировать в них Рефал, возможно придется применять различные
> механизмы.
>
> > -2- возможность привлечь к разработке волонтеров, которые не знают
> > (не хотят спешно изучать) Яву (например: Абрамов, Пономарева);
Арк:
Учитывая тезис, высказанный вначале письма, боюсь, что все-таки изучить
придется.
> >
> > -3- да и вообще, это выделение разумной независимой фазы ;-)
>
> Так то оно так... Если она сможет выделиться... ;-)
>
> >
> > Ну а фаза "АСАИЯ -->Ява" будет задачей на полчаса, для знатоков Явы...
> > Впрочем как и фазы "АСАИЯ -->Си", "АСАИЯ -->Си++", "АСАИЯ -->Т-язык".
> >
> > Вот и все, что я хотел бы сказать по Аликовму письму.
> >
> > Самый важный лично для меня тезис:
> > ========================
> > Андрей Слепухин! Срочно
> > захотелось иметь отдельную
> > фазу: Рефал Плюс-->АС
> > ========================
>
> Ну если вопрос так стоит... :-))) Как только AS зафиксируем - сразу
> займусь,
> благо что лексер уже есть (причем на Рефале).
Арк:
А кто зафиксирует? Андрей, мне кажется, мяч на твоей стороне:
за тобой очередная итерация.
>
> Всего доброго,
> Андрей
Всего наилучшего
Аркадий.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:58 MSD