Ada_Ru форум

Обсуждение языка Ада

Gela project

Оставить новое сообщение

Сообщения

Maxim Reznik
Gela project
2006-02-23 12:16:38

Hi, all

 

Хочу предложить вашему вниманию проект Gela

http://www.ten15.org/ada/

 

Цель проекта - создания нового компилятора языка Ада.

 

Русская версия документации

http://www.ten15.org/ada/docs_ru.html

 

Хотя занимаюсь этим довольно давно, сейчас удалось получить

первые обнадеживающие результаты. Поэтому и спешу поделиться.

 

Если кому-то инетресно позаниматься созданием компиляторов,

прочуствовать эти технологии своими руками (понаступать на

грабли собственноножно 8-) ) - присоединяйтесь!

 

PS Всех с праздиком!

 

--

Maxim Reznik

Хотел посмотреть исходники... Так фигушки, архив битый!

Архив там нормальный, только назван странно.

 

Посмотрел ASIS, как то, что сам хорошо знаю. Ничего не

понял. Самое ужасное - там нет НИ ЕДИНОГО КОММЕНТАРИЯ!

 

Ну их в баню!

On Thu, Feb 23, 2006 at 05:21:01PM +0300, Sergey I. Rybin wrote:

Архив там нормальный, только назван странно.

 

 

Да tar.bz2 довольно странный для Windows систем :-)

 

Посмотрел ASIS, как то, что сам хорошо знаю. Ничего не

понял. Самое ужасное - там нет НИ ЕДИНОГО КОММЕНТАРИЯ!

 

Да, за семь минут в нескольких Мб кода разобраться трудно! 8-)

Вместо комментариев могу предложить прочесть

http://www.ten15.org/ada/docs_ru.html

 

Я предпочитаю вместо комментариев употреблять понятные

идентификаторы, как советуют в Ada Quality & Style.

Получается весьма понятный код 8-)

 

procedure Read_File_And_Supporters

(The_Context : in out Concrete_Context_Node)

is

use Primary_Unit_Lists;

begin

The_Context.Compilation := List (Parser.Run (The_Context.This)); declare

Units : constant Compilation_Unit_List :=

To_Compilation_Unit_List (The_Context.Compilation.all); begin

for I in Units'Range loop

Normalizer.Run (Units (I));

end loop;

Normalize (The_Context);

 

for I in Units'Range loop

Asis.Gela.Implicit.Process_Unit (Units (I));

Read_Parent (The_Context, Units (I));

Read_Declaration (The_Context, Units (I));

Read_Withed (The_Context, Units (I));

Resolver.Run (Units (I));

end loop;

end;

end Read_File_And_Supporters;

 

 

 

Ну их в баню!

 

 

Ну как хотите

 

--

Maxim Reznik

Архив там нормальный, только назван странно.

 

Да tar.bz2 довольно странный для Windows систем :-)

 

Но форточный RAR его легко распаковал :)

 

Посмотрел ASIS, как то, что сам хорошо знаю. Ничего не

понял. Самое ужасное - там нет НИ ЕДИНОГО КОММЕНТАРИЯ!

 

 

Да, за семь минут в нескольких Мб кода разобраться трудно! 8-)

 

Извиняйте, дядьку, но в GNAT-ских исходниках начинаешь *разбираться"

с первой минуты. Именно что разбираться, а не гадать и восстанавливать

авторский замысел.

 

Вместо комментариев могу предложить прочесть

http://www.ten15.org/ada/docs_ru.html

 

Этого явно мало.

 

Я предпочитаю вместо комментариев употреблять понятные

идентификаторы, как советуют в Ada Quality & Style.

Получается весьма понятный код 8-)

 

Для серьезной программы - практика обязательная, но ни в коей

мере не в состоянии заменить нормального документирования.

 

Ну их в баню!

 

Ну как хотите

 

Дело не в хотении. Просто с индустриальной точки зрения этот проект

не существует. :(

On Thu, Feb 23, 2006 at 07:01:35PM +0300, Sergey I. Rybin wrote:

>Архив там нормальный, только назван странно.

Да tar.bz2 довольно странный для Windows систем :-)

Но форточный RAR его легко распаковал :)

 

 

На что я и расчитывал, откровенно говоря.

 

>Посмотрел ASIS, как то, что сам хорошо знаю. Ничего не

>понял. Самое ужасное - там нет НИ ЕДИНОГО КОММЕНТАРИЯ!

 

 

Да, за семь минут в нескольких Мб кода разобраться трудно! 8-)

 

Извиняйте, дядьку, но в GNAT-ских исходниках начинаешь *разбираться" с первой минуты. Именно что разбираться, а не гадать и восстанавливать авторский замысел.

 

 

Не могу ничего сказать, не пробовал. Хотя не из-за лени, а ради чистоты эксперимента, чтоб потом никто не говорил про derived work или как там...

 

Я предпочитаю вместо комментариев употреблять понятные

идентификаторы, как советуют в Ada Quality & Style.

Получается весьма понятный код 8-)

 

Для серьезной программы - практика обязательная, но ни в коей

мере не в состоянии заменить нормального документирования.

 

 

Согласен, что мало. Но нигде не видел документации по внутреннему устройству A4G. Прячите? Или обходитесь комментариями?

 

 

>Ну их в баню!

 

Ну как хотите

 

Дело не в хотении. Просто с индустриальной точки зрения этот проект не существует. :(

 

Пока или летально?

 

 

 

Я собственно хотел просить, каков был тот вопрос, ответ на который Вы не смогли найти в исходных текстах за 7 минут?

Я бы постарался добавить ответ в документацию...

 

В любом случае, если появятся вопросы, с удовольствием на них отвечу.

--

Maxim Reznik

Maxim Reznik wrote:

 

Согласен, что мало. Но нигде не видел документации по внутреннему устройству A4G. Прячите? Или обходитесь комментариями?

 

Внутри A4G есть полное описание структур данных. В каком файле - не помню, но точно помню, что там даже рисунки связей псевдографикой сделаны ;)

 

>Дело не в хотении. Просто с индустриальной точки зрения этот проект >не существует. :(

 

Пока или летально?

 

И всё же интересно:

 

1. Какие платформы поддерживает компилятор (CPU/OS).

 

2. Кто финансирует проект.

 

3. Кто заинтересован в результатах проекта.

 

К сожалению, если "положительных" ответов на эти вопросы нет, то диагноз

- "пока летально" :) Но всё можно исправить, главное, что бы нашелся кто-то, кто в этом заинтересован.

Maxim Reznik wrote:

 

В любом случае, если появятся вопросы, с удовольствием на них отвечу.

Есть вопрос ;)

 

Можно ли для пакетов сделать комментарии о назначении таковых?

 

И широко использовать контролируемые типы тоже не хорошо - слишком сильный удар по производительности. По крайней мере для хранения чисел (любых видов) вполне можно использовать сроку фиксированной длины.

Maxim Reznik wrote:

 

Я предпочитаю вместо комментариев употреблять понятные

идентификаторы, как советуют в Ada Quality & Style.

Получается весьма понятный код 8-)

 

Да, кстати, многие стили запрещают использование latin upper case I, очень часто она путается в latin lower case L.

Maxim Reznik wrote:

 

Хочу предложить вашему вниманию проект Gela

http://www.ten15.org/ada/

 

И ещё, я считаю, что использовать в качестве ASIS.Element ссылочный тип

- не есть хорошо. Это может очень плохо сказаться на надёжности конечных прикладных программ (и когда-то скажется!)

 

Всё же GNAT-ский стиль хранения данных в GNAT.Table мне нравится больше. И чем дальше - тем больше. Первый раз мы его опробовали на анализаторе поступающих формализованных сообщений (скорее - неформализованных, человеческий фактор). А потом он позволил за три недели создать прототип нашего дизайнера. Посему - рекомендую. А вот API уже никто не мешает делать в ОО виде. Каждый тип хранит внутри себя только номер записи в таблице. Плюсы - никакой контроль потерь памяти не нужен, структура записи таблицы запросто строится из UML диаграммы, код доступа и

установки атрибутов генерируется самостоятельно, шаблоны реализаций операций генерируются автоматически, достаточно простая ASIS программа позволяет производить обратный инжиниринг. Минус только один - удаление записа считай невозможно.

 

PS. Тут надо поблагодарить Сергея Игоревича, если бы не время,

потраченное им на обсуждение этого подхода, то сам подход мог бы и не состояться. СПАСИБО!!!

On Thu, Feb 23, 2006 at 08:16:13PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

Согласен, что мало. Но нигде не видел документации по внутреннему устройству A4G. Прячите? Или обходитесь комментариями?

 

Внутри A4G есть полное описание структур данных. В каком файле - не помню, но точно помню, что там даже рисунки связей псевдографикой сделаны ;)

 

Че-то мне больше нравится документация отдельно от исходных текстов. А чем вам http://www.ten15.org/ada/tree/Base_Element_Node.html

не описание структур данных?

 

 

>Дело не в хотении. Просто с индустриальной точки зрения этот проект >не существует. :(

 

Пока или летально?

 

И всё же интересно:

 

1. Какие платформы поддерживает компилятор (CPU/OS).

 

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

в нем вместо реальных типов, их размеров, aligment-ов указывается требования к типам. Ну как в Аде, к примеру для целых - диапазон. Получив такой файлик, его можно перенести на любую платформу, где есть "инсталлер", программка которая подставит реальные типы

исходя из требований, соптимизирует и получит .exe.

 

Вообще готов (под большим вопросом) пока только ASIS, а он ведь не зависим не от CPU, не от OS.

 

Ну а если говорить на чем это должно заработать скорее всего, то

думаю на моей домашней системе Linux/x86 8-)

 

2. Кто финансирует проект.

 

 

Ну я могу выдилить некоторые средства в размере скажем 10% от зарплаты 8-)

 

3. Кто заинтересован в результатах проекта.

 

Я! Мне очень интересно что из этого получится!

А вы не заинтересованы? 8-)

 

 

К сожалению, если "положительных" ответов на эти вопросы нет, то диагноз - "пока летально" :) Но всё можно исправить, главное, что бы нашелся кто-то, кто в этом заинтересован.

 

Ну сделаем ударение на слове "пока".

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Че-то мне больше нравится документация отдельно от исходных текстов. А чем вам http://www.ten15.org/ada/tree/Base_Element_Node.html

не описание структур данных?

 

Одно не отменяет другое. Отдельная документация может хорошо рассказать о целях и задачах, внешних требованиях, внутренних ограничениях,

архитектурных решениях, но вот приводить в ней детали реализации - неразумно.

 

 

Одной из идей которую хочется проверить, это возможность компиляции в "переносимый код", такой код - это особенность проекта TanDRA, в нем вместо реальных типов, их размеров, aligment-ов указывается требования к типам. Ну как в Аде, к примеру для целых - диапазон. Получив такой файлик, его можно перенести на любую платформу, где есть "инсталлер", программка которая подставит реальные типы

исходя из требований, соптимизирует и получит .exe.

 

Эта идея давно проверена - AS/400 тому двадцать лет как пример. Java и .NET примеры того же уровня, но по моложе.

 

 

Ну я могу выдилить некоторые средства в размере скажем 10% от зарплаты 8-)

 

Максим, не смеши... :) Я не думаю, что ты - хорошо замаскировавшийся миллионер. :(

 

Затраты на подобную работу даже в дешевом постсоветском пространстве будут составлять сотни тысяч USD.

 

 

Я! Мне очень интересно что из этого получится!

А вы не заинтересованы? 8-)

 

Тут позволю себе посплетничать о результатах. Самым полезным можно поставить возможность разработать новый стандарт ASIS 2005 в ОО стиле. Более специализированный - выработать технологию превращения XML

описаний в структуры данных и защитить на этом кандидатскую.

 

Всё остальное, скорее всего, достигнуто не будет.

 

 

Ну сделаем ударение на слове "пока".

 

И абсолютно правильно! ;)

On Thu, Feb 23, 2006 at 08:40:38PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

В любом случае, если появятся вопросы, с удовольствием на них отвечу.

Есть вопрос ;)

 

Можно ли для пакетов сделать комментарии о назначении таковых?

 

Можно. Приблизительно так:

Asis.ads/private part - абстрактый тип Element_Node - вершина иерархии Asis.* - процедурная обвертка вокруг ОО Asis-а,

Asis.Gela.Elements.* - сгенерированные пакеты с иерарзией типов OO Asis Asis.Gela.Classes - класификатор типов (Is_Signed_Integer, etc)

Asis.Gela.Implicit - создание неявных определений

Asis.Gela.Inheritance - создание наследуемых определений

Asis.Gela.Instances - макроподстоновка generic-ов

Asis.Gela.Iterator - итератор с возм. изменения дерева

Asis.Gela.Library - абстрагирование ада-библиотеки, поиск файлов

Asis.Gela.Normalizer - восстанавливание структуры из fixed-синтаксиса Asis.Gela.Overloads* - разрешение перегрузки операций

Asis.Gela.Visibility - разрешение имен, правила видимости

XASIS.* - утилиты не зависящие от ASIS реализации

 

xml/syntax.xml - исходный синтаксис Ады

xml/fix.xml - изменение синтаксиса под LL(1)

xml/asis_hier.xml - иерархия OO Asis

xml/code.xml - инструкции для автопостроителя parser.y

 

И широко использовать контролируемые типы тоже не хорошо - слишком сильный удар по производительности. По крайней мере для хранения чисел (любых видов) вполне можно использовать сроку фиксированной длины.

 

Это про что, я сразу не пойму? Asis.Element - не контролирруемые.

--

Maxim Reznik

Maxim Reznik wrote:

 

>И широко использовать контролируемые типы тоже не хорошо - слишком >сильный удар по производительности. По крайней мере для хранения чисел >(любых видов) вполне можно использовать сроку фиксированной длины.

 

Это про что, я сразу не пойму? Asis.Element - не контролирруемые.

Это касательно какого-то из *.Integers. Там стоит Unbounded_String как значение.

On Thu, Feb 23, 2006 at 09:54:08PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

>И широко использовать контролируемые типы тоже не хорошо - слишком >сильный удар по производительности. По крайней мере для хранения чисел >(любых видов) вполне можно использовать сроку фиксированной длины.

 

Это про что, я сразу не пойму? Asis.Element - не контролирруемые.

Это касательно какого-то из *.Integers. Там стоит Unbounded_String как значение.

 

 

А, это для арифметики с произвольной точностью. Ограничится

фиксированной длинной здесь не выйдет, т.к. точность заранее не

известна. Можно, конечно, исбавиться от контролируемых типов, но

так пока удобнее. За производительность будем бороться позже.

Говорят львиную долю ЦПУ в компиляторах хавает тупой сканер

выделяющий лексемы...

 

--

Maxim Reznik

On Thu, Feb 23, 2006 at 09:01:00PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

Хочу предложить вашему вниманию проект Gela

http://www.ten15.org/ada/

 

И ещё, я считаю, что использовать в качестве ASIS.Element ссылочный тип - не есть хорошо. Это может очень плохо сказаться на надёжности конечных прикладных программ (и когда-то скажется!)

 

Вот уж чего не пойму, так как это скажется на надежности прикладных программ? Они-то и увидеть не смогут, как реализован приватный тип.

Создаются все элементы при открытии контекста, удаляются при

закрытии. Думаю не трудно будет реализовать сборку мусора

(пока, правда, память не освобождается).

 

Всё же GNAT-ский стиль хранения данных в GNAT.Table мне нравится больше.

 

Наверное, это нужно на чем-то попробовать чтоб понять чем индекс в таблице лучше "индекса в памяти". В любом случае, если использовать теговые типы объекты прийдется создавать динамически. Так почему не держать в них и структуру?

 

Хотя имея иерархию ASIS в виде XML файла я могу легко менять

внутреннее представление объектов. Наверное это в чем-то

аналогично упоминаемому тобой UML.

 

И чем дальше - тем больше. Первый раз мы его опробовали на анализаторе поступающих формализованных сообщений (скорее - неформализованных, человеческий фактор). А потом он позволил за три недели создать прототип нашего дизайнера. Посему - рекомендую. А вот API уже никто не мешает делать в ОО виде. Каждый тип хранит внутри себя только номер записи в таблице. Плюсы - никакой контроль потерь памяти не нужен, структура записи таблицы запросто строится из UML диаграммы, код доступа и установки атрибутов генерируется самостоятельно, шаблоны реализаций операций генерируются автоматически, достаточно простая ASIS программа позволяет производить обратный инжиниринг. Минус только один - удаление записа считай невозможно.

 

 

Ну так если не удалять динамическую память, так и контроля памяти не надо 8-)

 

--

Maxim Reznik

PS. Тут надо поблагодарить Сергея Игоревича, если бы не время,

потраченное им на обсуждение этого подхода, то сам подход мог бы и не

состояться. СПАСИБО!!!

 

Скромно потупившись и ковыряя тапкой пол: да, иногда кое-что могем!

 

А подход и в самом деле на удивление удобный, логичный и глюкобезопасный.

Вообще готов (под большим вопросом) пока только ASIS, а он ведь не зависим не от CPU, не от OS.

 

Это только если DDA не учитывать :)

 

ВФ

Maxim Reznik wrote:

 

On Thu, Feb 23, 2006 at 08:16:13PM +0300, Vadim Godunko wrote:

 

Maxim Reznik wrote:

 

Согласен, что мало. Но нигде не видел документации по внутреннему

устройству A4G. Прячите? Или обходитесь комментариями?

 

Не прячу. Просто это был мой первый реальный проект, на котором я учился

много чему, причем - сразу. Я категорически недоволен тем, как я сам

откомментировал ASIS-ные потроха, особенно то, что было сделано в

самом нечале. Стараюсь по мере сил документацию улучшать.

 

В то же время, эта документация скорее работает, чем не работает.

С начала проекта прошло 10 лет, и я напрочь уже не помню, что и

как быо написано в первые пять. Иногда приходится влезать

и разбираться до упора. Документация реально помогает

 

Внутри A4G есть полное описание структур данных. В каком файле - не

помню, но точно помню, что там даже рисунки связей псевдографикой сделаны ;)

 

Да, есть такое - нарисовано, как реализована таблица контекстов (ASIS

умеет работать с несколькими одновременно открытыми контекстами,

с реализацией помучался, но вот до сих пор никому ни для чего не

понадобилось...)

 

Че-то мне больше нравится документация отдельно от исходных текстов.

 

Весь опыт AdaCore категорически восстает против такого подхода.

Исходники человек еще в состоянии содержать в порядке ПОСТОЯННО.

А исходники + отдельный документ - пару недель в лучшем случае...

Maxim Reznik wrote:

Одной из идей которую хочется проверить, это возможность компиляции

в "переносимый код", такой код - это особенность проекта TanDRA,

в нем вместо реальных типов, их размеров, aligment-ов указывается

требования к типам. Ну как в Аде, к примеру для целых - диапазон.

Получив такой файлик, его можно перенести на любую платформу, где

есть "инсталлер", программка которая подставит реальные типы исходя из требований, соптимизирует и получит .exe.

 

На сколько я слышал Ada хорошо компилится в java bytecode, а его потом

можно откомпилить с помощью gcj на любой системе поддерживаемой gcc.

Дешевая реализация вашей идеи.

 

И непонятно, зачем такие сложности с компиляцией в "переносимый код". Не

проще ли было написать front end к gcc? Сразу получалась бы поддержка

всех платформ, которые поддерживаются gcc без лишних сложностей.

 

Хотя java bytecode очень удобен для создания интерфейса пользователя.

(Если хочется создать нечто большее, чем веб клиент.) Добавьте и его в

планы возможных поддерживаемых платформ. :)

 

Я! Мне очень интересно что из этого получится!

А вы не заинтересованы? 8-)

 

BSD лицензия редкость для Ада компилятора. :) На текущий момент нет

свободно распространяемого компилятора подходящего для создания

коммерческих программ. Даже свободных программ, но под лицензией

отличной от GPL. (LGPL для библиотек, например). Так что если компилятор

получится, то востребован будет.

 

-- Olleg Samoylov

Что-то ко мне ara_ru-шные сообщения приходят в совершенно произвольном

порядке - сплошь и рядом сначала ответ на что-то, а потом то, на что ответ.

 

Одно не отменяет другое. Отдельная документация может хорошо рассказать

о целях и задачах, внешних требованиях, внутренних ограничениях,

архитектурных решениях, но вот приводить в ней детали реализации -

неразумно.

 

Любые ресурсы очень быстро оказываются конечными и недостаточными :(

Очевидно, что надо грамотно комментировать код. Очевидно, что надо

разрабатывать и сопровождать пользовательскую документацию. Все остальное -

опционально. То есть - либо плохо, либо никак, ибо ресурсов и на

обязаловку не хватает.

 

В начале проекта GNAT была опубликована пара статей (доклады на

конференциях), описывающих идеологию и общую архитектуру реализации

компилятора. И все...

 

Максим, не смеши... :) Я не думаю, что ты - хорошо замаскировавшийся

миллионер. :(

 

Затраты на подобную работу даже в дешевом постсоветском пространстве

будут составлять сотни тысяч USD.

 

Еще раз готов повторить - для Ады 83 минимальные ресурсы для разработки

"голого" компилятора (то есть - без примочек, инструментов и среды

разработки) оценивались в 100 человеко-лет. Практика лишь подтвердила

неумеренный оптимизм оценщиков.

 

А сколько стоит в год даже постсоветский разработчик?

 

Тут позволю себе посплетничать о результатах. Самым полезным можно

поставить возможность разработать новый стандарт ASIS 2005 в ОО стиле.

 

Стандарт - не получится. По причине необходимости обеспечить

upward compatibility. А вот разработать такое определение рядом со

стандартом - очень заманчивая идея.

 

Более специализированный - выработать технологию превращения XML

описаний в структуры данных и защитить на этом кандидатскую.

 

Да-да!

Новое сообщение:
Страницы: 1 2 3

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти