Семинар "Языки программирования и компиляторы"

Начинает работу семинар по языкам программирования и компиляторам.

Соруководители семинара: Михалкович С.С., Брагилевский В.Н., Пеленицын А.М.

Первое заседание семинара состоится 25 февраля в 16.00 в 304 ауд..

План семинара

  1. Доклад Михалковича С.С. “Компиляторы: синтаксический сахар и вязкая семантика”.
  2. Обсуждение примерной тематики следующих семинаров

Приглашаются студенты всех курсов и все желающие.

В первую очередь данное заседание семинара ориентировано на студентов 2 курса ФИИТ в связи с их предстоящим распределением по научным руководителям.

3 лайка

@Admin а не рассматривались какие-то другие варианты по времени? В 16:00, но не 25, а 24 или 26, например. Мне придётся специально приезжать.

Первое заседание подстраивалось исключительно под расписание студентов ФИИТ 2 курса. Мы с ними это обсуждали. Поэтому первый раз проведем в четверг, 25-го, в 16.00.

Про дни следующих заседаний, думаю, договоримся на первом. Меня лично устраивает и среда и пятница в 16.00

Хорошо.

Прошу произвести видеозапись доклада и опубликовать где-нибудь, если это возможно!

1 лайк

Напоминаю про семинар завтра тем, кто уже забыл.

1 лайк

Презентация доклада

Компиляторы-синтаксический сахар и вязкая семантика.pdf (852,7 КБ)

3 лайка

Видео семинара:

https://m.youtube.com/watch?v=lvc_eAHywxc

2 лайка

Я не понял, с чем вчера спорил Мирзоев, но полиморфные лямбды прекрасно объявляются в C++14:

#include <iostream>
using namespace std;

int main() {
	auto f = [](auto x) { return x*x; };
	
	cout << f(2);
	return 0;
}

https://ideone.com/aJbnus

1 лайк

Да, я ошибся.

Да, это здорово. Какие идеи - как это реализовать?

Посмотрите, как в Хаскеле реализовано (компилятор открыт), там и пишется короче. Тип лямбды выводится такой: Num a => a -> a.

Не, в Хаскеле другая архитектура. А почему Num? Из-за умножения?

Да, именно из-за умножения. Просто я хорошо отношусь к вам и к вашим ребятам и потому не хочу, чтобы вы реализовывали шаблоны так, как в C++.

А насчёт архитектуры — точно такая же, между парсингом и кодогенерацией проходов чуть побольше.

У нас в своё время Сергей Иванов реализовывал template class по синтаксическому дереву. Это были неуправляемые шаблоны в стиле C++ и его к сожалению не дописанная кандидатская. Именно он первым нашел статьи Сика. Именно он высказал прогрессивное предложение сохранять синтаксическое дерево для инстанции шаблонов. Жаль что не завершилось это

Как показывает пример Хаскеля, да и других функциональных языков, где параметрический полиморфизм стал использоваться намного раньше, чем он попал в мейнстрим, (например, ML), «неуправляемость» (что бы этот термин ни означал) или требование наличия исходного кода шаблона (как в C++) совсем не является необходимым требованием для реализации параметрических компонент. Кроме того, оттуда же понятно, что в них вполне можно контролировать типы до инстанцирования (подстановки типов-аргументов).

Насчёт того, что Сергей Иванов первым нашёл статьи Сика это сильное утверждение. Ну, для себя или для вас — может, первым…

Да, я это и имел в виду. Я узнал о статьях Сика впервые от Иванова. Насчет первенства всего остального - меня это не интересует, я согласен на любое первенство.

Да, очень бы хотелось модель хранения шаблонов чтобы их можно было восстанавливать не по тексту программы. В C++ это по-моему так и не дожали. Хотелось бы также чтобы по возможности отлавливалось побольше ошибок на ранних этапах компиляции. Идея реализации шаблонов в стиле C++ меня честно говоря до сих пор волнует.

В C++ обе проблемы: необходимость хранения исходного кода и невозможность «модулярного контроля типов» (то есть однократного контроля типов внутри шаблона) — происходят из-за требования стандарта языка C++ по алгоритму поиска имён.

[Зависимые] имена не связываются [при первом просмотре] и их поиск выполняется в точке инстанцирования шаблона как в контексте определения шаблона, так и в контексте точки инстанцирования.

— [С++03,14.6.2, пар. 1]

Подробно эта проблема давно описана в книге Герба Саттера (на русском она выходила под названием «Новые сложные задачи на C++», Задача 9).

Не было бы такого требования в этом алгоритме, не было бы и этих проблем. Алгоритм поиска имён в C++ вообще переусложнён. Так что не факт, что эта проблема действительно является фундаментальной…

Насколько я понимаю с алгоритмом поиска вся проблема в механизме перегрузки имён функций — самом беспорядочном способе обеспечения полиморфизма (в широком смысле слова): написал f(a), где a типа T (параметр шаблона) — и привет, эта f может быть чем угодно. Если это так, то ситуацию исправило бы ограничение любой из форм упорядоченного полиморфизма:

  • полиморфизма на основе подтипирования (в Java / C#),

  • полиморфизма на основе классов типов (так сделано в Хаскеле, это очень близко к обычной перегрузке, как известно из отличной статьи Фила Вадлера); так хотят рано или поздно сделать в C++;

  • или обе вышеперечисленные; видимо, это хорошо подошло бы для Паскаля, где есть и средства ООП в духе Java / C#, и свободные функции, как в Хаскеле и C++.

Для C++ есть ещё немаловажный аспект эффективности: традиционные реализации обеих форм, перечисленных выше, имеют накладные расходы (виртуальные функции и «словари», соответственно — про последние написано в статье Вадлера в разделе 4). Но для Паскаля, по идее, это не так важно.