Ответ на »сообщение 2597« (Рэйлвэй Каген)
___________________________
>>>"написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

А зачем компилятору ассемблерные вставки?

Ответ на »сообщение 2590« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2588« (RBV)
___________________________
Дежурная задачка: реализуйте на Хаскеле загрузчик модулей Оберона в память для Линукса
А программу для бразильской АЭС вам не написать ? :)) Ну и запросы у народа. Ща все все бросют и кинутся для RBV загрузчик модулей Оберона в память для Линукса писать. Я плакаль :))


А почему бы и нет?

Спокойно, Джек. Я предложил оценить вполне реальную системную задачу.

Кстати, программа для АЭС - это тоже интересно. :)

Ответ на »сообщение 2597« (Рэйлвэй Каген)
___________________________

Прошу прощения за overload, но я имел ввиду

"написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

Иначе теряется чистота эксперимента.

А конструкции языка в ходы выполнения ведь чем-то поддерживаются, не так ли? Ран-таймом. Поэтому чистота языка для реализации будет мнимой. К тому же не стоит забывать про метод раскрутки (bootstrapping): вы берете сокращенную версию языка с активным участием чужеродных кодов, а потом итеративно наращиваете компилятор, внедряя новые конструкции (заливая их "эпоксидкой"). С формальной точки зрения -- чистота сохранена (в расширенном языке). А в действительности -- плавает на чужом.

Думаю, Trurl, справедливо заметил относительно эффективности. Я разделяю эту точку зрения. Именно эффективности, а не потенциальной возможности.

Ответ на »сообщение 2580« (Trurl)
___________________________

Если интересно, язык называется SETL. Можно ли его назвать существующим - не знаю. Может быть правильнее - вымершим. Создан он был на рубеже 60-70-х и в свое время имел некоторую известность (в немалой степени благодаря тому, что на нем был написана первая "полноценная" реализация Ады). В СССР даже книга издана была "Язык сверхвысокого уровня СЕТЛ и его реализация".

Ну не совсем вымершим. Он еще теплится в своей альма-матер -- Курантовском институте в Нью-Йорке, только в виде SETL2.

Помнится, Дейкстра с некоторым скепсисом говорил о том, что русские непонятно зачем носятся с этим детищем профессора Шварца едва ли не как с писаной торбой. Насколько знаю, SETL (базирующий на работе со множествами) пришел с подачи А.П.Ершова (точнее даже, инициатором был А.А.Ляпунов -- учитель Ершова). Ершов разузнал про SETL (и пообщался со Шварцем) в ходе одного из своих визитов в Штаты. В отношении SETL Ершов и Дейкстра стояли на полярных позициях. Потом СЕТЛом занялась группа А.С.Нариньяни, точнее Д.Я.Левин с коллегами. Они реализовали ее сначала в ВЦ СО АН СССР в Новосибирске (на БЭСМ-6), а потом уже сменили дислокацию и в Российском НИИ искусственного интеллекта (который возглавляет А.С.Нариньяни, соратник А.П.Ершова и В.Е.Котова) создали несколько трансляторов для SETL (на базе проработанной ими абстрактной SETL-машины). Вполне вероятно, что в ряде проектов на уровне прототипирования/макетирования он в РосНИИ ИИ используется и поныне. Хотя внешних следов я там не встречал.

Стоит отметить, что разработка системы программирования и компилятора для языка Little на БЭСМ-6 была выполнена Л.В.Городней (1976) -- самым известным в Союзе специалистом по ФП. Этот язык системного программирования, похожий на Fortran, но обрабатывающий произвольные коды и приспособленный к крупноблочной организации программ и данных, был предложен Дж. Шварцем как средство реализации эффективной системы программирования для языка SETL.

SETL получил новый импульс развития у нас в ходе проекта МАРС (СТАРТ), в середине 1980-х годов (я о нем в свете Кроноса, транспьютеров и Модулы-2 здесь как-то рассказывал). И.В.Поттосин в конце 1990-х выделял наши реализации SETL и РЕФАЛ как хороший предмет для экспорта знаний-продуктов-технологий. Подробнее об истории SETL в нашей стране можно посмотреть в статье Давида Левина в музее Эдуарда Михайловича Пройдакова: http://www.computer-museum.ru/books/n_mozaika/setl.htm Она взята вот из этого сборника: http://www.iis.nsk.su/pottosin/40/win/title.htm

P.S. Кстати, раз уж речь зашла о РосНИИ ИИ. В отчете американцев о поездке в Советский Союз в конце 1950-х годов был признан приоритет СССР в направлении автоматического перевода с естественного языка на другой (у нас были даже машинные словари и технологии для китайского и японского). Американцы до этого тогда не додумались (или руки не дошли).

Ответ на »сообщение 2587« (Geniepro)
___________________________

Haskell мало подходит для написания рантаймов.
В принципе, написать можно. Например, сделать интерпретатор байт-кода. Но эффективность будет...
К тому же реально рантайм все равно будет на си.

Ответ на »сообщение 2594« (Руслан Богатырев)
___________________________


Есть два отнюдь не праздных вопроса:
1.можно ли написать компилятор Оберона на Хаскеле?
2.можно ли написать компилятор Хаскела на Обероне?

Прошу прощения за overload, но я имел ввиду

"написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

Иначе теряется чистота эксперимента.

Ответ на »сообщение 2595« (Lisp Hobbyist)
___________________________

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

Чтобы не было болтовни, нельзя ли ссылочку на сообщение, когда этот клуб ставил перед собой такую задачу?

Ответ на »сообщение 2583« (AVC)
___________________________

А здесь нам с непонятной гордостью предъявляют такую большую простыню. :)

А чем не повод для гордости? Я, любитель, который никогда не занимался целенаправленной оптимизацией скорости своих Лисп-программ, имея бесплатную версию не самой лучшей Лисп-системы, потратил полчаса на чтение документации (CLHS + документация к LW) и еще примерно столько же на эксперименты, и в итоге смог ИМХО добиться заметного эффекта по крайней мере, в "визуальном качестве" сгенерированного кода. А клуб пикейных жилетов на страницах этого форума за полгода не удосужился разобраться в реальном соотношении "программа/рантайм" в современных Лисп-системах, предпочитая просто генерировать информационный шум.

Ответ на »сообщение 2579« (Рэйлвэй Каген)
___________________________

Есть два отнюдь не праздных вопроса:
1.можно ли написать компилятор Оберона на Хаскеле?
2.можно ли написать компилятор Хаскела на Обероне?

Разумеется, можно. А с чем связаны сомнения? Реализация Хаскеля (как и любого другого языка) несет в себе "чистую", самостийную часть и "грязную", чужеродную часть. Эта чужеродная часть (ее фрагменты) может быть реализована на чем угодно (хоть в кодах процессора). Методом раскрутки можно получить псевдочистую вещь (где "грязь" осядет на самом донышке реализации).

Ответ на »сообщение 2572« (Lisp Hobbyist)
___________________________

А сейчас --- раскроем страшную тайну. :-)

Всегда интересно узнавать страшные тайны. Они на многое раскрывают глаза. Если есть языковая конструкция, прямое отображение которой в машинный код (из-за высокоуровневости) неэффективно. То появляется потребность в хинтовке -- ручках тьюнинга компилятора. Вполне допускаю (не вдаваясь в детали), что для очень многих языков неэффективность генерации кода может быть снивелирована множеством ручек (включая и ручную/автоматическую трансформацию критичных участков). Насколько я понимаю представленный Вами пример (благодарю за столь подробное раскрытие, это уже не более высокий и конструктивный уровень дискуссии), он показывает, что в отношении Лиспа сложился ложный стереотип относительно неэффективности генерации кода, которую хинтовкой и различными приемами можно привести к приемлемому виду.

Да, это одна из известных потенциальных угроз производительности, которую, если уж так прижмет, приходится обходить весьма жесткими методами (в частности, ценой может стать отказ от ФП со всеми его преимуществами).

Это замечание делает Вам честь. Как правило, достоинство любого инструмента одновременно является и его недостатком (для Оберона главная уязвимость -- сами модули). Для ФП, IMHO, интенсивная работа с динамическими структурами -- достоинство. Но они же являются и его недостатком (узким местом). Следовательно, для выбора приемлемости ФЯ к решению конкретной задачи, где подразумевается активная работа с динамическими структурами, необходимо иметь инструмент анализа (оценки/прогноза) "прожорливости" ресурсов. Было бы интересно узнать, какими возможностями располагает программист, приподнятый ФП над реальностью железа, для адекватной оценки и прогноза "просадки" -- возможностей масштабирования задачи. Нет ничего хуже, чем получив быстро красивый результат и пустив его в дело через некоторое время выяснить, что при м асштабировании просадка станет таковой, что потребует кардинальной переработки. "Автопилот" ФП в этом плане не может не настораживать. Или мои опасения напрасны?

ИМХО, любые тесты производительности, кроме профилирования реальных программ в реальных условиях их эксплуатации --- это самообман.

По-моему, и профилирование -- это самообман. При недетерминированности внешней среды (когда нельзя "заморозить" все внешние факторы, включая и операционное окружение) тестирование -- такой же самообман. Требуется куда более тонкий подход, когда можно аккуратно оценить проблемы производительности при отображении с языка на исполняемый код (неважно, промежуточный или машинный), а также специфику исполняющей системы и ее взаимодействие с операционным окружением. Разумеется, гипотезы должны перепроверяться профилированием по вполне определенной методике, составляемой с учетом специфики инструмента, конфигурации оборудования и операционной обстановки, а также задачи и проекта.