Домашки по курсу ФП 2025 оформлять в виде пулл-реквестов к этому репо. Если у вас уже был PR с некоторой подзадачей, допушивать изменения надо в тот PR. Создавать новый c тем же самым неправильно, нельзя, запрещено. История изненений должна быть линейной, то есть merge-коммиты запрещены (научитесь пользоваться git rebase)

Учебная группа имеет чатик в мессенджере. Все вопросы писать туда. В личку писать нельзя -- буду банить.

В директории /Lambda лежит шаблон-скелет, его нужно скопипастить (NEW_NAME=asdf make copy_template) и исправить под свои нужды:

• Указать автора (я должен быть способен сопоставить решение с ФИО в ведомости)
• Переименовать проект под свой мини-язык и пересобрать dune'ой. CI при сборке ожидает имя проекта, совпадающее с именем директории. И так как имя проекта это [a-zA-Z_]+, то у директорий с пробелами и символами # шансов пройти CI нет
• Cделать реализацию. Разработку рекомендуется вести итеративной моделью, а не водопадной.
• Изменять или удалять шаблон Lambda нельзя и запрещено (буду рисовать минус баллы).

Ожидается примерно следующая структура репозитория

• /Lambda -- шаблон проекта домашки, который редактирует только препод (вам необходимо будет его скопировать и переименовать, редактировать нельзя, удалившим его буду ставить минус баллы);
• /CSharpExc -- реализация мини-С# c исключениями, на основе шаблона /Lambda;
• /Java -- реализация мини-Java, снова на основе шаблона /Lambda;
• и т.д.

Для Merge Requests (a.k.a. pull requests) настроен CI, который смотрит в какой директории (проекте) произошли последние изменения, и именно в этой директории запускает сборку и тесты. Например, если поменялся файл Lambda/src/Parser.ml, то запустятся все тесты из директории проекта Lambda, а тесты из проекта Java запускаться не будут.

Также CI собирает документацию к миниязыку и выкладывает её в https://kakadu.github.io/fp2025/doc/LANGUAGE (например, вот так). А ещё измеряется покрытие тестами (например, так).

Настройка окружения: /DEV.md

Система оценивания подробно описана в grading.md.

Решения принимаются в виде пулл-реквестов к этому репо.

• В названии надо указать задачу, которую реализовывали, идентифицировать себя (фамилия, имя и курс, если возможны неоднозначности).

• Пулл-реквесты должны проходить CI

  • Ворнинги и ошибки компилятора должны быть исправлены

  • В том числе линтер (его замечания нужно исправлять);

  • проверку, что автоформатирование через ocamlformat настроено и соблюдается;

  • Все мои замечания по коду должны быть исправлены. - Если уверены, что исправили, пометьте как resolved - Если не уверены или они непонятны/некорректны, то опишитесь в комменте

  • DCO; скорее всего осилить Git aliases и добавить +1 сокращение будет достаточно:

    ````
    [alias]
        ci = commit -s
    ````
    

• К дереву абстрактного синтаксиса (AST) должны быть написаны комменты, какой конструтор за что отвечает. (Например, как здесь.)

• Используйте quoted string literals, чтобы не экранировать длинные строки руками

  let quoted_greeting = {|"Hello, World!"|}
  val quoted_greeting : string = "\"Hello, World!\""
  

• Да, объекты и присваивание запрещены.

• Иимена типов и функций -- snake_case

• Имена типов модулей и модулей -- CamelCase

Тесты нужны, чтобы убедить преподавателя, что вы таки запускали свою поделку на адекватных примерах. Большинство тестов будут интеграционные: запустил самописный интерпретатор миниязыка и сравнил с результатом (например, с поведением интерпретатора оригинального языка). В CI измеряeтся тестовое покрытие в процентах. Чем больше покрытие --- тем лучше. Если код не вызывается в тестах, то либо он не нужен, либо на него не написан тест, либо (в редких случаях) это бага ppx_bisect, который измеряет покрытие. Чтобы покрытие тестами таки считалось, не забывайте приписывать к своим библиотекам/исполняемым файлом заклинание в dune-файлах:

(instrumentation
  (backend bisect_ppx))