Функция Combine довольно умна, так что если во втором параметре она принимает полный путь (например, с именем диска), то значение первого параметра игнорируется. Таким образом, если путь к включаемому файлу задан полностью, то будет использоваться именно он, а не относительный путь, а если частично, то он будет рассматриваться как относительный путь.

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

В этом коде, однако, есть одна неочевидная хитрость. Обратите внимание на метод ElementsEx(), выделенный в коде красным. Это не метод XElement, а метод-расширение, написанный мной. Дело в том, что если первую строчку написать с использованием Elements(), то код будет генерировать исключение (NullReferenceException), если в файле спецификации не будет содержаться элемента Includes. Помните, выше я говорил про ложку дегтя? Это как раз она. Разработчики LINQ to XML утверждают, что данная библиотека предназначена для использования в функциональном стиле, но возврат null (в случае отсутствия данных) резко препятствует этому. В общем, на мой взгляд, это явная ошибка проектировщиков библиотеки. Чтобы обойти эту проблему, есть два пути:

1. Отказаться от функционального стиля и напичкать свой код if-ами, проверяющими на null все опасные места. Впрочем, в Nemerle if-ы – тоже выражения, но их применение сделает код более «рыхлым» и уж точно менее понятным.
2. Попытаться обойти эту проблему.

На мой взгляд, второй вариант более приемлем. Обойти возврат null можно, воспользовавшись оператором «??» и возвратив в случае null объект-фальшивку, не имеющий вложенных элементов:

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

Я выбрал второй вариант, так как он чище, короче и не приводит к созданию ненужных в данном случае объектов (фальшивок). Вот как выглядит метод-расширение ElementsEx:

Применение этого метода приводит к тому, что если элемент (в данном случае Includes) отсутствует и метод Element() возвратит null, то функция ElementsEx() просто возвратит пустой список, что как раз то, что нужно!

Библиотеки, которые действительно рассчитаны на применение в функциональном стиле, обычно пишутся так, чтобы не допускать возврата null. Вместо этого или возвращаются некие объекты-заместители, или результат помещается в специальный тип (вариант) option[T]. Этот вариант содержит два вхождения option[T].Some(x : T) и option[T].None(). Последний возвращается, если результат недоступен (например, запрошенный тег отсутствует). Это гарантирует, что во время исполнения не будет сгенерировано исключение NullReferenceException. При этом компилятор сам подскажет, что требуется проверить возвращаемое значение на «существование». Кроме того, это позволяет создать перегруженные методы-расширения, которые позволят добиться того же эффекта, что и приведенный выше метод-расширение ElementsEx():

Применение option[T] делает код более безлопастным и предсказуемым, однако приводит к созданию временных объектов-оберток, что может быть нежелательно в некоторых случаях (например, если метод, возвращающий option[T], используется в циклах с большим объемом итераций).

Чтение свойств

При наличии двух описанных выше функций чтение переменных из раздела Properties как основной, так и импортируемых спецификаций не представляет проблем:

Сначала загружаются свойства из импортируемых спецификаций, а затем – из основной. В результате свойства из основной спецификации «переписывают» (затирают) свойства из импортируемых спецификаций, так что основная спецификация может изменять часть импортируемых свойств. Например, спецификация может заменить некие процентные ставки, оставив неизменным алгоритм вычислений, импортируемый из включаемых спецификаций. При этом включаемые спецификации также могут содержать эти ставки, что позволяет использовать их независимо.

loadTemplateInfo

Локальная функция loadTemplateInfo загружает из раздела Template данные, описывающие файл шаблона, используемый для генерации отчетов по данной спецификации:

Код фактически самодокументирован. Пояснения требует только способ возврата результатов этой функции. Эта функция возвращает сразу несколько результатов. В C# я был бы вынужден или создать класс/структуру и вернуть данные через нее, или создать метод, возвращающий данные через out-параметры, или (если все возвращаемые значения имеют один тип) возвратить список объектов. Все перечисленные варианты приводят к существенному увеличению кода. Кроме того, они требуют передачи ссылки на спецификацию через отдельный параметр. В Nemerle же для возврата нескольких значений из функции можно воспользоваться кортежем. Идея кортежа очень похожа на идею списка аргументов функции. Если мы можем передать набор неименованных, разнотипных значений функции, то почему бы не делать то же самое при возврате значений из нее? Кортеж и является таким набором. В отличие от списка, количество элементов кортежа предопределено. Зато каждое значение кортежа может иметь уникальный тип.

Последняя строка функции loadTemplateInfo – это формирование и возврат кортежа:

А первая строка за ней – это вызов этой функции и одновременная декомпозиция возвращаемого ею кортежа:

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

Описать тип кортежа можно, перечислив типы входящих в него элементов через звездочку – «*». Так, тип для loadTemplateInfo() будет: «string * string * XElement». Именно это вы увидите, если подведете курсор к имени функции.

makeReport

Предыдущие функции подготавливали необходимую информацию для функции makeReport. Она принимает XML-элемент из раздела Items вместе с его порядковым номером и формирует отчет. Ниже приведен код этой функции и код, ее вызывающий.

На мой взгляд, в этом коде нечего объяснять, разве что конструкцию:

Она заменяет цикл вида:

Другими словами, этот код перечисляет индексы коллекции. Первая запись лучше отражает суть алгоритма. Так что если вам она кажется непонятной, не спешите с выводами. Скорее всего, вы просто к ней не привыкли.

calcVarsValues

Подробности реализации appPrinter я поясню чуть позже, а пока давайте рассмотрим реализацию движка скриптов, позволяющего производить вычисления внутри спецификации. Эту возможность выполняет функция calcVarsValues:

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

calcOneVarValue

Как видите, все, что делает calcVarsValues – вызывает calcOneVarValue для каждого имени переменной (вхождения словаря). Однако код calcOneVarValue уже намного сложнее. Вот он:

Эта функция проверяет, содержится ли в строке символ «$» (именно им помечаются ссылки на переменные и вычисляемые выражения); если символ не найден, то ничего не делается. Если же символ найден, то производится разбор строки на предмет распознавания в ней тех самых ссылок на переменные и выражения. Код парсинга подобных конструкций очень сложен. Фактически даже код выявления $-выражений весьма непрост, а уж парсинг самих выражений и подавно. К счастью, всю эту работу можно переложить на функцию make_splice_distribution(), находящуюся в модуле Helper из пространства имен StringTemplate, которое является частью стандартной библиотеки макросов Nemerle. Изначально эта функция была создана для реализации $-строк в Nemerle (вы не раз видели их в коде выше), а потом была адаптирована для использования в библиотеке Nemerle.StringTemplate (типизированный аналог широко известной в узких кругах скриптовой библиотеки StringTemplate, доступной на Ява и .NET).

Функция make_splice_distribution() позволяет разобрать строку и вычленить из нее части. Части представляются вариантом StrPart (из того же пространства имен). Вот его описание:

• Lit – описывает литерал, т.е. часть строки, не содержащую выражений.
• Expr – описывает выражение (потенциально оно может быть любым выражением Nemerle).
• NewLine – описывает перевод строки (т.е. символ «\n»).
• IndentedExpr – описывает выражение, перед которым идет «отбивка». Эта вхождение варианта нужно в макробиблиотеке StringTemplate, но для данного случая его можно рассматривать как пару, состоящую из литерала и выражения.

Функция make_splice_distribution использует компилятор. Поэтому для ее использования придется создать специальный класс CompilerHost:

Экземпляр CompilerHost находится в практически одноименной переменной compilerHost, которая объявлена выше по коду (вне вычислительных функций), и которая захватывается контекстом данной функции (это обеспечивает возможность ссылаться на один экземпляр данного класса, сколько бы вычислений выражений не производилось).

Собственно, функции make_splice_distribution требуется не сам CompilerHost, а создаваемый внутри него объект CoreEnv, хранящий контекст парсинга. Кроме того, make_splice_distribution требуется начальное местоположение (относительно файла с кодом) и строковое значение, которое предстоит разобрать. Конечно местоположение (Location) желательно было бы задать поточнее, но лень снова взяла верх, и я отказался от этой прекрасной идеи.

После выполнения make_splice_distribution нужно разобрать возвращаемый ею список. Сначала я написал рекурсивную функцию, которая делала это, но потом, немного подумав, заменил ее на foreach, так как он более точно отражает суть происходящего. Внутри цикла (foreach) производится обратная сборка строки (которая была разобрана с помощью make_splice_distribution). Но при этом производится вычисление выражений. Это делается с помощью функции calcSplice, описанной выше по коду. Ее код я приведу чуть ниже. А пока я объясню, зачем нужен if, идущий за циклом.

Задачи данной проверки – определить наличие рекурсии в выражениях, предотвратить ее и выдать внятное сообщение об ошибке.

Рекурсия возникает вследствие того, что функция calcOneVarValue может быть вызвана из calcSplice (а та исходно вызывается из calcOneVarValue).

Так вот, для предотвращения рекурсии имена переменных значения, которых вычисляются в данный момент, помещаются в параметр recursionSet (типа HashSet). HashSet позволяет быстро определить, содержится ли в нем некий ключ, и не допускает дублирования ключей. Фактически HashSet – это упрощенная HashSet (именно поэтому в .NET Framework долгое время не было класса, аналогичного HashSet, но слава богу, теперь он есть).

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

Пора вернуться к описанию пропущенной функции calcSplice.

calcSplice

Эта функция вычисляет значение одного $-вхождения:

Функция make_splice_distribution возвращает выражения, обернутые в вызов функции Convert.ToString(), а для интерпретатора это совершенно лишнее, так что первое, что требуется сделать – это вынуть само выражение из параметра Convert.ToString(). Для этого используется, пожалуй, самая мощная возможность Nemerle – сопоставление с образцом. Более того, в качестве образца используется кусок кода. точнее квази-цитата.

Квази-цитата – это участок кода ограниченный скобками . Этот код не превращается в MSIL. Он превращается в AST языка Nemerle. AST этого языка создан из вариантов. Именно этот факт позволяет использовать квази-цитаты не только для конструирования (порождения) кода, но и для его распознавания. Чтобы можно было распознавать неполные образцы, в квази-цитаты можно добавлять $-вхождения. В них могут находиться имена переменных, которые связываются с любыми значениями. Так вот, образец сопоставляется с выражением, состоящим из вызова метода Convert.ToString, и любым подвыражением, передаваемым ему в качестве аргумента. При этом с именем expr связывается значение этого подвыражение. Таким образом, за знаком => и вплоть до следующего образца или до конца тела оператора match можно использовать это имя для получения доступа к подвыражению. Второй образец «term» сопоставляется вообще с любым выражением и связывает имя term с ним. Это позволяет удобно сообщить об ошибке (впрочем, ошибка в данном случае маловероятна).

calcPExpr

Локальная функция calcSplice – это по сути маленький интерпретатор выражений, встроенный (посредством механизма локальных функций) прямо в середину программы. Это самая большая функция, которая практически не содержит вложенных функций (одна маленькая не в счет!). Она принимает на вход выражение в формате PExpr (это формат представления кода в компиляторе Nemerle) и вычисляет (интерпретирует) его.

Эта функция большая, так как по сути она состоит из образцов, разбирающих отдельные типы вырежений. Чтобы не запутаться в ней, лучше всего сначала взглянуть на нее в свернутом виде:

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

Образцы вида « » разбирают бинарные выражения. Переменные e1 и e2 при этом связываются с подвыражениями, стоящими соответственно справа и слева.

Все операторы вычисляются одной универсальной, обобщенной локальной функцией calcOper. Перед этой функцией стоит ключевое слово «and», а не «def», как обычно. Это вызвано тем, что эта функция взаимно рекурсивна с предыдущей функцией – calcPExpr. Таким образом, с одной стороны, calcPExpr должна знать о существовании calcOper, но и calcPExpr должна знать (и мочь вызвать) calcOper. Но в Nemerle локальные функции «видят» только то, что объявлено выше них. Так вот, объявление одной из функций через «and» решает эту проблему.

Так как calcOper очень мала, ее код приведен выше, в описании функции calcSplice. Функция calcOper производит вычисление обоих аргументов (для этого рекурсивно вызывая calcPExpr), преобразует полученный результат к double и передает их в функцию, переданную ей (функции calcOper) в качестве второго аргумента. Этой функцией являются операторы. За счет того, что calcOper является обобщенной функцией, она может принимать в качестве параметра как операторы сравнения, так и арифметические операторы.

Кстати, сами операторы преобразуются в функции с помощью очень приятной возможности Nemerle – частичного применения. Так если взять, например, оператор «==», то запись «_ == _» будет эквивалентна записи «(x, y) => x == y». Правда, короче и понятнее? И это в сравнении с почти идеальным синтаксисом лямбд Nemerle и C# 3.0, а по сравнению с анонимными методами C# 2.0 или обычными методами это вообще сестра таланта 🙂

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

Думаю, пояснения здесь излишни.

Данная конструкция распознает оператор if (что, в общем-то, и так очевидно для тех, кто хорошо знаком с квази-цитированием и сопоставлением с образцом). Остается только интерпретировать подвыражения и поместить полученные значения в «реальный» if:

when $»$name» == «НомерЭлемента»

Данный образец распознает вызов функции без параметров, имя которой – «НомерЭлемента». Точнее, сам образец распознает вызов любой функции с пустым списком аргументов, а gurd-выражение «when $»$name» == «НомерЭлемента»» уже определяет что название функции именно «НомерЭлемента». Вам может показаться непонятным выражение «$»$name»». На самом деле это всего лишь $-строка, содержащая имя одной переменной. Я использую такую запись, чтобы не писать name.ToString(), так как последняя запись длиннее (а gurd-выражение и так не короткое). Преобразование к строке требуется, так как имена в парсере Nemerle хранятся запакованными в специальный класс (сопоставление с образцом для которого будет выглядеть чересчур громоздко).

Таким образом, данный образец «найдет» вызов функции НомерЭлемента(). Так как это встроенная функция, возвращающая порядковый номер отчета (элемента), то все что требуется сделать – это вернуть значение переменной num.

Этот образец распознает все остальные вызовы функций (как с параметрами, так и без). При этом имя, как и в прошлом случае, связывается с переменной name, а список аргументов связывается с переменной args.

Список аргументов содержит выражения в формате PExpr. Для вызова функции требуется преобразовать их в массив значений типа object. Это делается одним вызовом метода расширения MapToArray (код которого находится в модуле Utils):

Ему в качестве параметра передается локальная функция calcPExpr, производящая вычисление одного выражения, и MapToArray применяет ее ко всем значениям, тем самым выполняя требуемую задачу. Обратите внимание на это, так как многие императивные программисты могут в подобной ситуации начать лепить циклы. Это не только значительно длиннее, но и провоцирует ошибки.

За вызов функции отвечает метод Call, расположенный в модуле ScriptFuncs. Этот модуль будет описан ниже.

Модуль ScriptFuncs

Задача этого модуля – предоставить интерфейс для регистрации методов, написанных на .NET-языках, в качестве функций скрипта. Реализуется это довольно просто. На стадии загрузки с помощью вызова метода RegistrFunc (см. выше) производится регистрация необходимых методов. При этом получаемая информация о типах этих методов закладывается в хэш-таблицу. При этом ключом служит пара («имя метода» * «количество параметров»). При вызове производится поиск метода с заданным именем и соответствующим количеством параметров. Если такой метод есть, производится преобразование типов аргументов таким образом, чтобы они соответствовали типам, описанным в информации о типах вызываемого метода, и производится вызов. Вызов производится динамически через рефлексию. Это, конечно, не быстро, зато полюбуйтесь, как это просто реализовать:

Ref(name)

Этот паттерн сопоставляется со ссылкой на переменную. Так что надо «залезть» в словарь переменных и посмотреть, есть ли она там. Если есть, вернуть ее значение (предварительно вычислив), а если нет – выдать сообщение об ошибке:

Набор referencedVars содержит переменные, на которые были ссылки из значений других переменных. Эта статистика собирается чтобы информировать пользователя о возможных проблемах (неиспользованных переменных).

Literal(. )

Данный паттерн распознает литералы.

Значения литералов практически без изменений возвращаются функцией calcPExpr. Единственное исключение – это Literal.Integer, который хранится в несколько сложном виде. Его значение хранится как ulong, знаковое число или беззнаковое определяется отдельным полем, и еще в одном поле тип данных в формате компилятора Nemerle. Это приводит к тому, что требуется преобразовать тип числа и возвратить в него знак. Чтобы не мучиться, я решил использовать тип long (он же Int64).

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

doReplace

Локальная функция doReplace производит замену подстановочных значений соответствующими значениями переменных. Перед этим она вычисляет список «неиспользованных» переменных (т.е. переменных, на которые не было ссылок ни из выражений в других переменных, ни в шаблоне). Вот ее код:

Кроме того, во время замены заместителей значениями переменных создается список неизвестных заместителей, т.е. заместителей, присутствующих в файле шаблона, но не совпадающих с именем ни одной переменной.

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

Выдача сообщений об ошибках

В конце работы метода DoReport() производится вывод предупреждений и сообщений об ошибках.

Сначала на консоль выводится список заполнителей, не совпадающих ни с одним именем переменной.

А затем выводится список ошибок, сформированный за время генерации отчета. В списке присутствуют как предупреждения, так и ошибки (начинающиеся со строки «Ошибка:»). Чтобы пользователь мог лучше выделить ошибки, они выделяются красным. Для этого сообщения фильтруются с помощью локальной функции printMessagese.

Обратите внимание, что этой функции в качестве параметра передается фильтр. Это ни что иное, как функция, которая принимает строку и возвращает булево значение, говорящее, удовлетворяет ли строка условиям фильтрации.

Также обратите внимание, что метод-расширение из состава стандартной библиотеки Nemerle (FilterLazy) используется в паре с методом-расширением из библиотеки LINQ. Несмотря на то, что первый метод получает ссылки на функции через функциональный тип, а второй – через делегат в коде, они выглядят одинаково и естественным образом сочетаются.

Заключение

Эта статья имела несколько целей.

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

Во-вторых, хотелось показать, как легко можно работать с XML средствами LINQ to XML.

В-третьих, она предоставляет код (ну, или на худой конец приемы и подходы), который может быть в той или иной мере использован при создании собственных систем. Например, подобный скриптовый движок может быть очень удобен в системе управления предприятием для формирования текстовых значений документов. При этом словари могут наполняться не только из XML, но и из БД, а то и из других источников.

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

Источник