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

Поддержка учебных курсов ФИИТ, 2 курс
#1

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

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

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

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

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

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

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

3 лайка
#2

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

#3

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

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

#4

Хорошо.

#5

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

1 лайк
#6

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

1 лайк
#7

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

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

3 лайка
#9

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

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

2 лайка
#10

Я не понял, с чем вчера спорил Мирзоев, но полиморфные лямбды прекрасно объявляются в 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 лайк
#11

Да, я ошибся.

#12

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

#14

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

#15

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

#16

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

#17

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

#18

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

#19

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

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

#20

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

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

#21

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

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

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

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

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

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

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

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

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

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