Редкая птица долетит до середины Днепра, не каждый разработчик осилит все паттерны в WL. Нет ему равных языков в паттерн-матчинге. Чуден и необычен язык этот. Изобилует он точками, подчеркиваниями, да запятыми так, что в глазах рябит, да разум мутнеет.

В этой статье я постараюсь сделать как можно более подробный обзор на механизм сопоставления с образцом в Wolfram Language (WL) и покажу реальные примеры, где я сам и мои товарищи его активно используют. А также я поделюсь всеми неочевидными тонкостями работы с шаблонами, с которыми лично я столкнулся в процессе написания кода на WL. По возможности я буду приводить примеры на других языках программирования - на Python и C#. Это позволит всем, кто не знаком с WL лучше понять код и сравнить синтаксис.

Оглавление

1. Введение

2. Несколько примеров на Python

3. Терминология

4. Чем будем пользоваться

5. MatchQ

6. Switch

7. Cases

8. Replce*

9. Set*

10. Шаблоны

11. Точное сравнение

12. Все что угодно

13. Связывание

14. Заголовок

15. Шаблон последовательности

16. Повторяющийся шаблон

17. Альтернатива

18. Значение по умолчанию

19. Опции

20. Проверка шаблона

21. Условие

22. Дословное сопоставление

23. Удерживание

24. Определения

25. Заключение

Введение

Сейчас почти во всех популярных языках программирования существует такая штука, как "паттерн-матчинг" или "сопоставление с образцом/шаблоном". Изначально этот метод обработки структур данных появился в классических функциональных языках программирования и постепенно перекочевал в языки общего назначения. В Python паттерн-матчинг появился в версии 3.10, в C# он появился в версии 7, в JavaScript его нет и сейчас. В функциональных языках программирования, например в F# или в Scala, механизм сопоставления с образцом существует уже давно и имеет достаточно высокую гибкость. Но мы здесь ради Wolfram Language. В нем сопоставление с образцом появилось в версии 1.0, которая была выпущена в 1988 году. Т.е. тогда, когда все перечисленные выше языке еще не существовали. Конечно же, я ради справедливости должен упомянуть Lisp, как один из самых важных функциональных языков в истории, где сопоставление с шаблоном было еще раньше.

Прежде чем начать писать эту статью я постарался изучить паттерн-матчинг в других языках программирования. Так я познакомился с ним в C#, Python, Scala, F#. Ради справедливости я выбрал два языка общего назначения и два функциональных языка. Причем, я хочу отметить, что в каждом языке я нашел что-то новое и полезное для себя. Последние версии C# позволяют использовать очень сложные шаблоны, Python мне понравился своей простой использования, в Scala мне больше всего понравилась конструкция case class MyClass, а F# предоставил огромное разнообразие шаблонов и синтаксического сахара с вычурными конструкциями. После этого у меня и родилась идея написать эту статью, чтобы поделиться с сообществом еще одним взглядом на паттерн-матчинг, который существует в языке Wolfram.

Несколько примеров на Python

Все любят Python и именно поэтому я выбрал его в качестве примера для демонстрации возможностей и изучения отличий, а также чтобы не пугать уважаемых читателей шаблонами WL в первом же разделе. Итак, в Python шаблоны появились недавно, а поэтому пока что их синтаксис не самый разнообразный. Что на мой взгляд даже хорошо, так как большое разнообразие может только запутать программиста. Я очень надеюсь, что в будущих версиях Python механизм сопоставления с образцом будет улучшаться, но его простота и лаконичность сохранятся на том же уровне, что и сейчас. Собственно несколько примеров.

Можно сравнить некий объект напрямую с конкретным значение:

number = 1
match number:
    case 1:
        print('один')
    case 2:
        print('два')

Или же использовать так называемый wildcard, который означает "что угодно", если ни одно из предыдущих сравнений не подошло:

number = 2
match number:
    case 1:
        print("один")
    case _:
        print("не один")

Кроме того, мы можем сопоставлять объекты с шаблонами, которые представляют собой списки или словари:

list1 = [1, 2]
match list1:
    case []:   
        print('пустой список')
    case [x]:
        print('список с одним элементом x = {0}'.format(x))
    case [x, *_]:
        print('много элементов, а первый элемент x = {0}'.format(x))

Собственно выше показана еще одна возможность - это связывание локальных переменных с частями из объекта во момент сопоставления. Так например сравнивая список с набором шаблонов - во втором и третьем случае мы сделали так, что при удачном сравнении первый элемент списка присваивается переменной x.

И последнее, что я покажу, но не последнее в принципе - это сравнение с целыми классами. Это хорошо работает с классами, которые помечены атрибутом dataclass:

from dataclasses import dataclass

@dataclass
class Coordinate:
    x: int
    y: int
    z: int

coordinate = Coordinate(1, 2, 3)
match coordinate:
    case Coordinate(0, 0, 0):
        print('Начало координат')
    case _:
        print('Любая другая точка')

В общем-то и все. Я думаю, что уважаемые читатели намного лучше меня знают как работает сопоставление с образцом в Python, но я должен был привести несколько примеров выше, чтобы было понятно о чем примерно будет идти речь в следующих разделах статьи. Часть примеров я взял из статьи "Pattern matching. Теперь и в Python", которую опубликовал автор @topenkoff.

Терминология

Так как в следующих частях статьи мы рассматриваем Wolfram Language, то сначала нужно уточнить терминологию. Чаще всего "сопоставление с образцом" я буду называть "сравнение с шаблоном".

В языке Wolfram не существует объектов в привычном понимании этого слова, которое справедливо для популярных языков программирования, в нем есть только атомы и выражения.

Атом - аналог примитивных типов - это число, строка или символ.

Выражение - аналог сложного объекта. Все выражения состоят из атомов и только из них. Ниже несколько примеров атомов:

1           (* атом с типом Integer, т.е. целое число *)
2.0         (* атом с типом Real, т.е. действительное число *)
1/3         (* атом с типом Rational, т.е. рациональное число *)
4 * I       (* атом с типом Complex, т.е. комплексное число *)
"string"    (* атом с типом String, т.е. строка *)
variable    (* атом с типом Symbol, т.е. имя переменной/функции/типа *)

Код выше вполне валиден, т.е. это не абстрактный пример. Его можно скопировать и выполнить и он даже сработает.

А еще он примечателен тем, что эти 6 строк содержат в себе все существующие атомы в языке Wolfram. Все остальное будет считаться выражениями, которые в конечном итоге всегда можно разделить на атомы. Хоть и в физике давно известно, что реальные атомы еще как делятся, но в WL они, увы, неделимы.

Иногда я буду говорить про объекты в WL, но знайте - я имею ввиду сложные выражения, которые просто выполняют роль объектов. Т.е. {1, 2, 3} - это массив целых чисел, но на самом деле массивы - это тоже выражения. А конструкция Point[{1, 2, 3}] по логике представляет собой объект - структуру данных для представления точки в пространстве, но в терминах WL - это тоже выражение.

Комментарии в языке Wolfram отделяются с помощью "колючих скобочек" (**), т.е. вот такими последовательностями:

code[ (* комментарий *) ] (* еще одни комментарий *)

Чем мы будем пользоваться

В языке Wolfram существует достаточно много функций, которые работают с шаблонами. По правде говоря, АБСОЛЮТНО ВСЕ функции, переменные, выражения, константы и структуры в Wolfram Langage работают с шаблонами, но делают это незаметно. Мы же в первую очередь рассмотрим их явное применение. А чтобы их применять мы должны познакомиться с некоторыми полезными функциями.

MatchQ

Первая такая функция - это MatchQ[expr, pattern]. То есть она принимает первым аргументом выражение, а вторым шаблон и сравнивает их. При удачном сравнении функция возвращает True, а если выражение и шаблон не матчатся - False. В частном случае, когда вместо паттерна передается любое другое выражение - эта функция работает просто как Equals, т.е. выполняет сравнение напрямую. И тут мы вспоминаем первый пример на Python, где объект сравнивался с конкретными значениями, так как это по сути является аналогом этой возможности case из Python:

MatchQ[1, 1] (* => True *)
MatchQ[{1, 2, 3}, {1, 2, 3}] (* => True*)

Я могу переписать первый пример на Python вот так при помощи функции If:

number = 1
If[MatchQ[number, 1], 
  Print["один"], 
  If[MatchQ[number, 2], 
    Print["два"]
  ]
]

Согласитесь выглядит не очень красиво.. пока код небольшой - это еще более менее читаемо, но уже громоздко. Может быть есть какая-то альтернатива?

Switch

Да, она есть и представляет собой почти полный аналог синтаксиса match/case из Python. Синтаксис ее использования вот такой:

Switch[expr, 
  pattern1, 
    result1, 
  pattern2, 
    result2
]

Т.е. первый аргумент - это выражение, которое необходимо сопоставить, далее каждый четный аргумент - это шаблон, а каждый нечетный начиная с третьего - это результат, который будет возвращаться. Аргументов должно быть нечетное количество. Кстати говоря, как обычно код выше вполне валиден и будет работать, но не сделает ничего полезного:

В очередной раз мы пронаблюдали очень важное свойство WL! Как только интерпретатор не знает что делать с выражением, то он возвращает его как есть в неизменном виде. К этому надо просто привыкнуть, ведь WL - это функциональный язык программирования, а по принципам ФП любой вызов функции всегда должен возвращать результат. Даже если его нет - это значит, что он просто равен Null. То есть я его не вижу, а он есть..

Но все поменяется, как только я что-то изменю в коде выше. Например, я задам символу expr значение... другого символа pattern2!

expr = pattern2

Switch[expr, 
  pattern1, result1, 
  pattern2, result2
]

У Switch есть один недостаток - эта функция не предназначена для связывания. Она позволяет только сравнивать выражения и шаблоны, т.е. на самом деле она больше похожа на классический switch/case из C#, чем на match/case из Python. Для этого есть другая функция, которая называется Cases.

Cases

У этой функции следующий синтаксис:

Cases[expr, pattern]

Еще у нее есть множество перегрузок, но они пока что нам не интересны. Что она делает? По умолчанию она "вытаскивает" из выражения expr то, что матчится с pattern. Я не зря выделил жирным предлог "из", так как это важный момент. Потому что Cases по умолчанию ищет совпадение внутри выражения, а не производит сравнение с самим выражением. Звучит контринтуитивно, но на самом деле эта функция в первую очередь служит для разбора сложных выражений на части и там она справляется как нельзя лучше. Вот так я могу выбрать все единички из списка при помощи Cases:

Cases[{1, 2, 3, 4, 1, 2, 3, 1, 2, 1}, 1] (* => {1, 1, 1, 1} *)

То есть функция пробежалась по массиву слева, вызвала на каждом элементе MatchQ[item, 1] и если вернулось True, то "выбрала" результат. Но казалось бы, причем тут связывание?

Rule (→), RuleDelayed (↦)

Если добавить в функцию Cases не просто шаблон, а "правило" для шаблона, то у нас появится возможность связывать переменные с частями выражения слева. Это на самом деле проще показать в виде кода, чем объяснить словами.

Cases[{expr1, expr2}, x_ -> x + 1] (* или *)
Cases[{1, 2}, x_ :> x + 1]

Чтобы понять что произошло выше - я просто напишу как нужно читать пример этот пример: "Выбрать из списка {expr1, expr2} слева все элементы, которые соответствуют шаблону x_ и прибавить к результату выбора число 1 и вернуть в виде списка".

Во втором случае я использовал RuleDelayed (:>) ради разнообразия. И тот и другой способ в общем случае работают одинаково с одной небольшой разницей. Rule - не удерживает аргументы, а RuleDelayed - удерживает. Про удерживание будет в следующих разделах, но если коротко, то разница такая:

1 + 1 -> 2 + 2
1 + 1 :> 2 + 2

Replace* (/., //.)

И предпоследняя функция, которая работает с шаблонами и правилами - это функция Replace. У нее есть родственные функции, такие как ReplaceAll и ReplaceRepeated. Что эти функции делают? Правильно выполняют замену. Вот как это работает:

x /. x -> y (* это сокращение для ReplaceAll[x, x -> y] *)

Как правильно читать пример выше: заменить в выражении слева все, что матчится с левой частью правила на правую часть правила. Замена для более сложного выражения будет выглядеть вот так:

expr = Sin[1/x] + Cos[x^2]

expr /. x -> (x + Pi)

expr /. x -> 4.2

Естественно, кроме прямой замены конкретных значений мы можем использовать шаблоны, но об этом как раз дальше.

Set, SetDelayed, UpSet, UpSetDelayed, TagSet, TagSetDelayed

И наконец последняя функция. Да, это присваивание во всех его формах. Все 6 функций очень полезны и лично я их активно использую. Но нам будет достаточно рассмотреть только одну, которая применяется чаще всего - это SetDelayed. Ее сокращенный синтаксис это :=. А причем здесь шаблоны? Дело в том, что во время присваивания для создания определений язык Wolfram не использует сигнатуры, т.е. имя функции + набор параметров. WL всегда использует шаблоны. Простейшее создание определения с помощью отложенного присваивания (SetDelayed или :=) выглядит вот так:

f[x_] := x + 1

Код выше на самом деле представляет собой ничто иное как выражение на языке Wolfram, которое в чуть более полной форме выглядит вот так:

SetDelayed[f[x_], x + 1]

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

Что в итоге делает ядро? Определение сохраняется во внутреннем хранилище языка почти в том же виде, в котором мы его и записали: левая часть шаблон, а правая - выражение. Когда пользователь передает в ядро выражение, например f[1], то оно начинает искать определения для символа f, находит и выбирает при помощи MatchQ первый подходящий шаблон, для которого выполнится MatchQ[f[1], f[x_]] === True. Ну и затем ядро берет правую часть и подставляет единичку на место x.

Весь этот процесс выше и есть то самое неявное повсеместное использование шаблонов в WL. Все устроено таким образом потому что в ядре нет таблицы методов с сигнатурами. Есть только списки правил с шаблонами. А значит любой вызов функции - это по сути применение паттерн-матчинга. А как же переменные? Они устроены по-другому? Ответ - нет. При извлечении значения переменной - тоже происходит паттерн-матчинг в точно такой же таблице с правилами и шаблонами. Только сами шаблоны будут попроще.

Шаблоны

Статья уже получилась достаточно большой, а мы только приступили к шаблонам. Мы рассмотрели функции, которые с ними работают, а теперь рассмотрим сам синтаксис шаблонов, но для начала нужно ответить на один очень важный вопрос: что же такое эти шаблоны? Насколько я могу догадываться в Python или в C# шаблоны - это просто синтаксический сахар, который интерпретатор/компилятор раскрывает в более традиционные конструкции - то есть в условные операторы. В Python не существует шаблона самого по себе как полноценного объекта, с которым можно работать. Все тоже самое можно сказать и про C#. Напротив, в языке Wolfram шаблоны - это самые настоящие выражения и они обладают всеми свойствами обычных выражений. Это значит, что я могу использовать шаблоны не привязываясь к тому месту, где я это делаю. Wildcard в Python имеет смысл внутри блока match/case, а аналог в WL можно использовать везде. Это пожалуй основное и важнейшее отличие шаблонов в WL от паттерн-матчинга в языках общего назначения, где шаблоны не являются объектами, а представляют собой часть синтаксиса, который состоит из операторов и ключевых слов. А теперь приступим к их рассмотрению.

Точное сравнение

Оно уже было и в принципе интуитивно понятно. Но я покажу еще раз:

MatchQ[1, 1] === True

То есть я убедился в том, что 1 == 1. Если это более сложное выражение, то выглядеть все будет вот так:

MatchQ[
  f[g[x, y], z], 
  f[g[x, y], z]
] (* => True *)

Но есть один нюанс, который важен при работе с числами или сложными выражениями, на которые наложено множество переопределений. В WL существует функция Equals (==) и SameQ (===). Они работают немного по разному. Первую функцию мы будем назвать сравнением, а вторую - точным сравнением. Вопрос - какая из этих двух функций используется если мы сопоставляем точные значения? Понять это можно просто экспериментируя:

{1 == 1, 1 === 1, MatchQ[1, 1]}

{1.0 == 1, 1.0 === 1, MatchQ[1.0, 1]}

{a == b, a === b, MatchQ[a, b]}

Как хорошо видно из примера выше - MatchQ при сопоставлении с точным значением работает как так же как и точное сравнение SameQ. Поэтому по крайней мере при работе с числами или с символьными выражениями в разной форме нужны быть очень аккуратным в использовании MatchQ. Хоть мы и знаем, раскрывается сумма квадратов, но это не значит, что раскрытая и нераскрытая сумма будут равны:

MatchQ[(a + b)^2, a^2 + 2*a*b + b^2]

(a + b)^2 == a^2 + 2*a*b + b^2

FullSimplify[(a + b)^2 == a^2 + 2*a*b + b^2]

В списке функций из раздела выше в самом конце были функции из семейства Set*. А здесь я говорю, что точные значения в функциях, работающих с шаблонами, тоже являются шаблонами. Это что получается, я могу использовать точное значение для создания определений? На самом деле да! Когда мы создам определение функции, то не обязательно в качестве параметра должна идти переменная. Можно использовать и константу и конкретное сложное выражение и оно не будет восприниматься как переменная. Допустим я хочу создать рекурсивную функцию. На всем множестве целых чисел она вызывает сама себя:

fib[n_] := fib[n - 1] + fib[n - 2]

Вызовем эту функцию:

fib[4] (* => recursion limit *)

Кажется нам чего-то не хватает в определении. Нужно учесть то, что если параметр n == 0 или n == 1, то нужно возвращать конкретные значения. В каком-нибудь другом (Python) я бы сделал вот так:

def fib(n: int) -> int: 
    if n == 0: 
        return 0
    if n == 1: 
        return 1
    return fib(n - 1) + fib(n - 2)

fib(10)

Можно сделать тоже самое на WL:

fib[n_] := 
Switch[n, 
  0, 0, 
  1, 1, 
  _, fib[n - 1] + fib[n - 1]
]

fib[10]

Но есть и другой способ. Я могу использовать перегрузку вот так:

fib[0]  := 0
fib[1]  := 1
fib[n_] := fib[n - 1] + fib[n - 2]

fib[10]

Таким образом мы нашли еще одно принципиальное отличие WL от популярных языков программирования. Шаблоны вместо сигнатур => точное значение - это тоже шаблон => функции можно определять на точных значениях. В этом плане механика WL чем-то похожа на JavaScript. Любая функция в JS - это объект, но объекту на ходу можно добавить свойства. Единственное отличие в том, что в JS вызов функции и получение свойства немного отличается, а в WL они будут идентичны.

А вот реальный пример, который и я и мои товарищи активно используем в своих проектах - это кэширование значений функций, которые меняются редко и очень медленно. В нашем конкретном случае происходит кэширование HTML-страниц на сервере:

SetAttributes[Cache, HoldFirst]; 


Cache[expr_, period_Integer: 60] := 
Module[{roundNow = Floor[AbsoluteTime[], period]}, 
	If[IntegerQ[Cache[expr, "Date"]] && Cache[expr, "Date"] == roundNow, 
		Cache[expr, "Value"], 
	(*Else*)
		Cache[expr, "Date"] = roundNow; 
		Cache[expr, "Value"] = expr
	]
]; 

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

Шаблон "все что угодно" (_)

А теперь мы приступаем к изучению простейшего шаблона, который представляет собой "все что угодно", т.е. это wildcard для WL. Записывается он как ни странно точно так же - в виде единичного подчеркивания. При использовании вместе с функциями, которые мы рассмотрели выше, этот шаблон будет матчится с любым выражением:

MatchQ[1, _]               (* => True *)
MatchQ[{1.0, 1/2, 3*I}, _] (* => True *)
MatchQ["string", _]        (* => True *)
MatchQ[name, _]            (* => True *)
MatchQ[f[g[x, y]], _]      (* => True *)

А еще я могу заменить любое выражение или выбрать любое выражение:

x = 1.0

Switch[x, 
  1, 
    Print["целое число"], 
  _, 
    Print["не целое"]
]

Cases[f[1, 2.0, -3/4, 5*I], _ :> x]

g[1, 2, 3] /. _ :> x

Последний пример довольно примечателен. Интуитивно я ожидал, что произойдет замена внутри выражения g[..], но в итоге заменилось выражение g[..] целиком. Ведь оно все целиком матчится с _.

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

validVersionQ::argex = "incorrect arguments"

validVersionQ["13.3"] = True
validVersionQ["13.2"] = True
validVersionQ["13.1"] = False

validVersionQ[_] = (Message[validVersionQ::argex]; Null)

Код выше определен для трех конкретных строк, а для всего остального будет печатать ошибку "incorrect arguments" и возвращать Null.

Связывание

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

users = {
  <|"Name" -> "Kirill", "Role" -> "QA"|>, 
  <|"Name" -> "Ivan", "Role" -> "Student"|>
}

Cases[users, <|"Name" -> name_, "Role" -> "Student"|> :> name]

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

Cases[users, <|key_ -> name_, "Role" -> "Student"|> :> f[key, name]]

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

points = RandomInteger[10, {3, 2}]

forces = Flatten[Table[gforce[p1, p2], {p1, points}, {p2, points}]]

forces /. gforce[p_, p_] :> Nothing

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

home = <|"Type" -> "Building", "Address" -> <|
     "City" -> "Saratov", 
     "Street" -> "Tankistov"
|>|>; 

me = <|"Name" -> "Kirill", "Address" -> <|
     "City" -> "Saratov", 
     "Street" -> "Ogorodnaya"
|>|>; 

Cases[{home, me}, <|_, "Address" -> <|_, "Street" -> street_|>|> :> street]

Кроме тогда, связывание при помощи конструкции x_ является сокращенной формой записи шаблона. Его более полная форма выглядит как x: _ (хотя на самом деле самая полная форма это Pattern[x, Blank[]]). Используя синтаксис с двоеточием, я могу связать не только одно любое значение в целевом выражении, но и более сложные части. Ниже пример того, как можно из списка можно выбрать только те списки, которые состоят из трех элементов и просуммировать их:

Cases[{{1}, {1, 2}, {1, 2, 3}, {3, 2, 1}, {3, 2}, {2}}, 
  x: {_, _, _} :> Total[x]
]

Заголовок

Кроме того, что я показал выше способ как выбрать любое выражение при помощи wildcard, в WL есть множество других форм шаблонов. Одной из них как раз является указание имени шаблона, которую мы рассмотрели только что. Следующая форма - это указание заголовка для целевого выражения. Заголовок в частых случаях можно рассматривать как тип выражения. Если вернуться назад, то можно вспомнить про 6 типов атомов, которые существуют в языке. Когда я их перечислял - я указал, что все они имеют свой тип. Например целое число имеет тип - Integer, а действительное - Real. Так вот этот тип и есть заголовок для целых и действительных чисел. Почему я называю это заголовок? Если мы вспомним, то все в Wolfram является атомом или выражением. Все выражения состоят из двух частей - головы и тела. По сути голова или заголовок - это то, что идет в выражении перед квадратными скобками, а тело - то что находится внутри квадратных скобок. Понять какой заголовок у выражения можно при помощи специальный функции Head. Опять же на коротких примерах становится понятно как она работает, и самое главное, что значит термин "заголовок":

Head[1] (* => Integer *)
Head[2.0] (* => Real *)
Head[1/3] (* => Rational *)
Head[4.0 + I] (* => Complex *)
Head["string"] (* => String *)
Head[x] (* => Symbol *)

И что же нам это дает? Дело в том. что любой заголовок можно использовать в качестве указания на тип выражения в шаблоне. Т.е. при сопоставлении можно точно проверить какого типа выражение указав тип вот так _Type:

MatchQ[1, _Integer]     (* => True *)
MatchQ[1/3, _Rational]  (* => True *)
MatchQ[1.23, _Real]     (* => True *)
MatchQ[I, _Complex]     (* => True *)
MatchQ["s", _String]    (* => True *)
MatchQ[x, _Symbol]      (* => True *)

Выше мы использовали списки {} и ассоциации <||>, какие же типы у них?

Head[{}]   (* => List *)
Head[<||>] (* => Association *)

Значит проверить, что выражение это список или ассоциация можно так:

MatchQ[<||>, _List]        (* => True *)
MatchQ[<||>, _Association] (* => True *)

А еще мы можем использовать этот способ для обработки данных. Пусть у меня есть какой-то набор данных в виде списка ассоциаций. Я знаю, что в нем есть ассоциации, которые нужно превратить в JSON-объект и списки, которые нужно превратить в JSON-массив. Сначала я создам небольшое выражение, которое мы будем конвертировать в JSON:

expr = jsonObj[
  jsonNode["key1", "value1"], 
  jsonNode["key2", 2], 
  jsonNode["arr1", jsonArr[1, 2, 3, 4]]
]

Теперь я создам правило замены, которое будет превращать выражения в строки:

toJSONRules = {
  jsonNode[k_String, v_String] :> k <> ": " <> v, 
  jsonNode[k_String, v_Integer] :> k <> ": " <> ToString[v], 
  jsonArr[v__] :> "[" <> StringRiffle[Map[ToString, {v}], ", "] <> "]", 
  jsonObj[s__String] :> "{" <> StringRiffle[{s}, ", "] <> "}"
}; 

Что делают правила выше? Они проходят все выражение насквозь и только в тех местах, где шаблон матчится с частью выражения происходит замена. Так как наше выражение имеет несколько уровней, то оно не сразу преобразуется в окончательный вид - json-строку. Для этого потребуется применить правила три раза:

expr /. toJSONRules

expr /. toJSONRules /. toJSONRules

expr /. toJSONRules /. toJSONRules /. toJSONRules

Но вообще-то я могу сказать, что jsonNode[k, v] - это некий объект и у него есть свой тип - jsonNode. Тогда я могу создать для него отдельную рекурсивную функцию, которая преобразует объект в строку:

jsonToString = Function[node,
  Switch[node,
    _String, 
      node, 
    
    _Integer, 
      ToString[node], 
    
    _jsonArr, 
      "[" <> StringRiffle[Map[jsonNodeToString] @ Apply[List] @ node, ", "] <> "]", 

    _jsonNode, 
      node[[1]] <> ": " <> jsonNodeToString[node[[2]]], 

    _jsonObj, 
      "{" <> StringRiffle[Map[jsonNodeToString] @ Apply[List] @ node, ", "] <> "}"
  ]
]

Шаблон последовательности (__, ___)

В одном из примеров выше я использовал двойное подчеркивание, так как там без него было не обойтись. Но что оно значит? Все очень просто - это расширение синтаксиса одиночного "что-угодно" на последовательность из "чего-угодно" длиной от одного элемента до бесконечности. То есть:

MatchQ[{1}, {__}] (* => True *)
MatchQ[{1, 2}, {__}] (* => True *)
MatchQ[{1, 2, 3}, {__}] (* => True *)

Этот шаблон похож на *_ в Python, который обозначает все остальные аргументы после тех, которые указаны точно. С этим шаблоном можно использовать и связывание и указание заголовка. Допустим у меня есть список, где подряд идут сначала целые числа, а затем действительные и я не знаю сколько их. Вот так я могу поделить список на две части:

{1, 2, 3, 3.0, 2.0, 1.0} /. {
  ints__Integer :> {ints}, 
  rels__Real :> {rels}
}

(* Out[] = {{1, 2, 3}, {3.0, 2.0, 1.0}} *)

В Python конструкцию *_ можно использовать только один раз в текущем расположении, так как она по умолчанию будет захватывать все, что не связано при помощи переменных или одиночного wildcard. Но в WL можно использовать двойное подчеркивание любое количество раз. Но как это работает?

Cases[{
    {1, 2, 3}, 
    {1, 2, 3, 4}
  }, 
  {first__, rest__} :> <|"first" -> {first}, "rest" -> {rest}|>
]

Как видно из результата, в этом случае сопоставление происходит слева направо и останавливается как только происходит первое совпадение с образцом. То есть проходя выражение насквозь сначала сначала связывается переменная first = 1, а затем переменная rest = 2, 3. Необходимо учитывать этот порядок сопоставления при использовании нескольких подчеркиваний подряд.

Мы рассмотрели шаблон, соответствующий одному или нескольким выражениям в виде последовательности. Но есть еще шаблон, которые представляет собой последовательность, где может быть любое число элементов. Как нетрудно догадаться из подзаголовка раздела - это тройное подчеркивание ___.

MatchQ[{}, {___}]           (* => True *)
MatchQ[{1}, {___}]          (* => True *)
MatchQ[{1, 2, 3, 4}, {___}] (* => True *)

Такой шаблон позволяет проверять на соответствия пустые списки и выражения, если это требуется бизнес логикой.

А теперь я придумаю сам себе задачу и героически ее решу. Допустим у меня есть список. Я хочу найти в этом списке все тройки игроков элементов, где первый и третий равны, а второй элемент - любой другой. Пусть у меня есть список:

array = {1, 2, 1, 4, 5, 6, 7, 8, 7, 4, 2, 1, 3}; 

Моя цель - выбрать из этого списка подпоследовательности:

{1, 2, 1}
{7, 8, 7}

Как это сделать с текущими знаниями? Очевидно, что можно попробовать Cases, но нужно придумать правильный шаблон:

Cases[{array}, {___, x_, y_, x_, ___} :> {x, y, x}]

Здесь я использовал тройное подчеркивание, так как не знаю сколько элементов может быть в начале и в конце, а последовательность шаблонов x_, y_, x_ как раз указывает на то. что первый и третий элемент должны быть равны. Что же в итоге получится?

Выбралась только первая последовательность. А еще мне пришлось поместить весь исходный список внутрь другого списка. Есть ли способ сделать все тоже самое, но чтобы Cases проходил не по списку элементов, а брал целиком весь массив и скал совпадения образца в последовательности элементов? Конечно да!

SequenceCases[array, {x_, y_, x_} :> {x, y, x}]

Шаблон повторяющихся элементов (expr.., expr...)

Вы думали, что несколько вариантов подчеркивания - это все, что пришло в голову разработчикам Wolfram Research? Как бы не так! Для повторяющихся шаблонов у них припасен еще один трюк. Все, что мы рассматривали в предыдущем разделе было связано с функциями, родственными Blanc (_) и Sequence ( x, y, z). Но есть еще ряд функций-шаблонов для повторяющихся элементов, которые родственны Repeated. Сначала пример:

MatchQ[{a, a, b, b, b}, {a.., b..}] (* => True *)

Две точки после символов a и b как раз являются сокращенным синтаксисом для записи Repeated. В чем отличие этого способа от предыдущего? Дело в том, что шаблоны последовательностей и wildcard не могут покрыть те случаи, где мы точно знаем, что повторяется не любое выражение, а какое-то конкретное. Например несколько переменных подряд. Но еще важнее то, что с помощью этого способа мы можем сказать интерпретатору, чтобы он искал повторение сложных структур. Например вот так можно определить, что двумерный список - это список координат, где каждая точка - это пара действительных чисел:

MatchQ[{{1.0, 1.0}, {2.0, 4.0}, {3.0, 9.0}}, 
  {{_Real, _Real}..}
]

• _Real - матчится с любым действительным числом

• {_Real, _Real} - с любым списком из двух чисел

• {_Real, _Real}.. - последовательность пар длиной от одного до бесконечности

• {{_Real, _Real}.. } - непустой список где только пары действительных чисел

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

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

MatchQ[{a, b, c, a, b, c}, {PatternSequence[a, b, c]...}] (* => True *)
MatchQ[{}, {PatternSequence[a, b, c]...}]                 (* => True *)

Выше видно, я использовал еще один вид шаблона - PatternSequence. Он может пригодиться при сравнении с последовательностями, если точно известно число элементов, которые в ней должны быть, но их не обрамляет никакой заголовок.

Но кроме повторения ноль-бесконечно и один-бесконечно раз есть еще возможность указать точное число повторений, либо количество повторений в некотором диапазоне. Увы, для этого нет сокращенного синтаксиса, но пусть у нас есть список:

array = {1, 1/2, 3, 1/4, 5, 1/6}

Мы можем ограничить число повторений сверху вот так:

MatchQ[array, {Repeated[_, 5]}] (* False, т.е. 5 - максимальное число повторений *)
MatchQ[array, {Repeated[_, 7]}] (* True *)

Указать максимальное и минимальное число:

MatchQ[array, {Repeated[_, {4, 8}]}] (* True, от 4 до 8 *)

Либо точное число:

MatchQ[array, {Repeated[_, {6}]}] (* True т.е. должно быть ровно 6 элементов *)
MatchQ[array, {Repeated[_, {7}]}] (* False *)

А еще можно ограничить число повторений снизу вот так:

MatchQ[array, {Repeated[_, {6, Infinity}]}] (* True *)

Все тоже самое работает не только для Repeated (..), но и для RepeatedNull (...):

MatchQ[array, {RepeatedNull[_, {6, Infinity}]}] (* True *)

Альтернатива (a | b)

Речь идет о шаблоне вида:

MatchQ[a, a | b] (* => True *)
MatchQ[b, a | b] (* => True *)

В принципе, особо объяснения не требуется. Эта конструкция по сути является логическим или для шаблонов. Конечно же применять его можно применять к самым разным выражениям. Например у нас есть набор, где каждая точка - дата и значение. Дата может быть как в формате DateObject[{y, m, d, ..}], так и в формате абсолютного времени или строки. А сами данные могут быть списком, а могут быть одним числом. Как создать шаблон, который проверяет вот такую структуру данных:

timeseries = {
  {3911241600, {41000, 42500, 40800, 42000}}, 
  {DateObject[{2023, 12, 12, 12}], 42770}, 
  {"Tue 12 Dec 2023 16:08:22", 41600}
}; 

Все очень просто. У нас должно быть повторяющееся выражение в виде списка из двух элементов, где первый - это дата, абсолютное время или строка, а второй - список или число. Звучит просто!

MatchQ[timeseries, {
  {
    _Integer | DateObject[__] | _String,
    _Integer | {Repeated[_Integer, {4}]}
  } ..
}]

(* Out[] = True *)

Но есть одно неочевидное применение это функции и шаблонов в целом. Я могу применить альтернативу не только к значениям внутри выражения, но и к заголовкам! Допустим у меня есть две структуры данных. Они похожи внутри, но в зависимости от заголовка они должны обрабатываться по разному. Тогда я могу создать шаблон, которому подойдет сразу несколько заголовков, если я делаю что-то общее для разных типов. Пусть у меня есть структура MyList и MyArray. И та и другая содержат внутри список элементов, но способ добавления и извлечения значений отличаются. Что если я хочу создать одну общую функцию и для списка и для массива?

myList = MyList[{1, 2, 3, 4, 5}]
myArray = MyArray[{1, 2, 3, 4, 5}]

И допустим я хочу просуммировать данные внутри этих массивов. Вот как можно это сделать:

sum = Function[collection, 
  Total[collection /. (MyList | MyArray)[data: {__Integer}] :> data]
]

sum[myList]  (* => 15 *)
sum[myArray] (* => 15 *)

А теперь интересный пример. Допустим у меня есть некие типы данных. Пусть - Cat и Dog. Вот они:

Jessica = Cat["Jessica", "Type" -> "Cat", "Age" -> 1.5]
Rebert = Dog["Robert", "Type" -> "Dog", "Age" -> 2.5, "DogBreed" -> "Welsh Corgi"]

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

getAge[(Cat | Dog)[___, "Age" -> age_, ___]] := age

Таким образом мы определили функцию сразу на двух похожих типах. Более того. мы можем связать имя типа и переменную:

getTypeAndAge[(anamal: Cat | Dog)[___, "Age" -> age_, ___]] := {animal, age}

А вот кстати еще один реальный пример использования альтернативы из пакета реализующего протокол WebSocket:

WebSocketSend[client_, message: _String | _ByteArray] := 
BinaryWrite[client, encodeFrame[message]]; 

Значение по умолчанию

Этот шаблон в основном используется при создании определений. Синтаксис вот такой:

func[x_, y_: 1] := x + y

Если использовать более полный способ записи именованного шаблона, то мы получим сразу два двоеточия:

func[x_, y: _: 1] := x + y

И тогда при вызове функции будут следующие результаты:

func[1]     (* => 11 *)
func[1, 2]  (* => 3  *)

Еще один вариант - использование специального хранилища Default:

Default[func, 2] = 10
func[x_, y_.] := x + y

func[1]     (* => 11 *)
func[1, 2]  (* => 3  *)

Очевидно, что данный синтаксис - это реализация параметров по умолчанию при помощи шаблонов. То что в Python делается вот так:

def func(x, y = 10): 
  return x + y

В WL реализовано при помощи паттернов. Но есть две важные особенности.

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

func[n_Integer: 1, x_Real: 2.0, r_Rational: 1/3] := 
{n, x, r}

И все три аргумента имеют значение по умолчанию. Тогда благодаря указанию типов я могу пропустить как первый аргумент, так и второй:

func[1/4]    (* => {1, 2.0,  1/4} *)
func[2.45]   (* => {1, 2.45, 1/3} *)
func[3, 1/5] (* => {3, 2.0,  1/5} *)

Но если порядок неправильный, то результата не будет:

func[1/4, 1] (* => func[1/4, 1] *)

Еще одно важное свойство значения по умолчанию - использование не только в определениях. Естественно, его можно использовать вообще везде, где только придет в голову. Например во время замены:

f[5, 5] /. f[x_, y_: 10] :> x + y (* => 10 *)
f[5] /. f[x_, y_: 10] :> x + y    (* => 15 *)

Более того, я могу использовать хранилище Default для этих целей:

Default[f, 2] = 10 (* 2 означает второй аргумент по умолчанию *)

f[5] /. f[x_, y_.] :> x + y  (* => 15 *)

Опции

Но кроме значений по умолчанию бывают еще и именованные аргументы. Я могу создать метод на C#, где будут аргументы по умолчанию и во время вызова функции передавать имена параметров:

public int method1(int x = 1, int y = 2, int z = 3)
{
    return x + y + z; 
}

var r1 = method1(y: 5); // => 9

Есть ли что-то похожее в WL? Конечно да - опции или опциональные аргументы. Для опций есть собственный отдельный шаблон, который так и называется OptionsPattern:

Options[func] = {
  "opt1" -> 1, 
  "opt2" -> 2
}

func[x_, OptionsPattern[]] := 
x + OptionValue["opt1"] + OptionValue["opt2"]

func[1]              (* => 4 *)
func[1, "opt1" -> 3] (* => 6 *)
func[1, "opt2" -> 3] (* => 5 *)

Как видно в коде выше - для получения текущего значения опции используется специальная функция - OptionValue. В качестве опциональных имен аргументов я указал строки, но все тоже самое сработает и с символами, т.е.:

Options[func] = {opt -> 1}

func[OptionsPattern[]] := OptionValue[opt]^2

func[]             (* => 1   *)
func["opt" -> 2 ]  (* => 4   *)
func[opt   -> 10]  (* => 100 *)

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

func[OptionsPattern[{opt1 -> 1, opt2 -> 2}]] := 
OptionValue[opt1]^2 + OptionValue[opt2]^2

func[opt1 -> 2] (* => 8 *)

А еще можно наследовать опции от других символов и функций. Пусть у меня есть функция:

Options[func1] = {opt1 -> 1, opt2 -> 2}

func1[x_, OptionsPattern[]] := x + OptionValue[opt1] + OptionValue[opt2]

func2[opts: OptionsPattern[func1]] := func1[10, opts]

func1[1] (* => 4  == 1  + 1 + 2 *)
func2[]  (* => 13 == 10 + 1 + 2 *)

Наследовать опции можно даже от нескольких функций. Для этого их необходимо указать в виде списка имен в OptionsPattern, а далее нужно точно указать опцию какой функции необходимо извлечь в OptionValue:

Options[func1] = {"opt" -> 1}; 
Options[func2] = {"opt" -> 2}; 

func3[opts : OptionsPattern[{"opt" -> 3, func1, func2}]] := {
  "FromF1" -> OptionValue[func1, {opts}, "opt"],
  "FromF2" -> OptionValue[func2, {opts}, "opt"],
  "FromF3" -> OptionValue["opt"]
}

func3[]           (* => {"FromF1" -> 1,"FromF2" -> 2,"FromF3" -> 3} *)
func3["opt" -> 5] (* => {"FromF1" -> 5,"FromF2" -> 5,"FromF3" -> 5} *)

Можно ли использовать этот шаблон сам по себе в других функция? Ведь это полезно только именованных аргументов по умолчанию? Как обычно да. Если у вас есть набор опций, полученный во время вызова других функций, то вы всегда можете проверить его на корректность вот так:

MatchQ[
  {{x -> y}, y :> z, g -> {1, 2, 3}}, 
  OptionsPattern[]
] (* => True *)

А при помощи Cases или Replace набор опций всегда можно разобрать.

И последняя тонкость по использованию опций. Значение по умолчанию легко сделать вычисляемым на ходу. То есть чтобы оно не было константой. Достаточно заменить обычное правило (->) на отложенное (:>):

Options[dateString] = {date :> Now}

dateString[OptionsPattern[]] := DateString[OptionValue[date], {"DateShort"}]

dateString[]
dateString[date -> Yesterday]

Проверка шаблона

А теперь познакомимся с еще одной функцией - PatternTest. С ее помощью можно создать такой шаблон, который будет вызывать пользовательскую функцию на выражении и возвращать True или False, что означает матчится шаблон или нет. По сути это аналог ограждающей конструкции из Python:

number = 10
match number: 
  x if 0 <= x < 10: 
    print("цифра")
  _: 
    print("число")

Такого же эффекта можно добиться при помощи следующего синтаксиса в WL:

number = 10

MatchQ[number + 1, _?(0 <= # < 10&)]
MatchQ[number - 1, _?(0 <= # < 10&)]

То есть необходимо сначала указать любой шаблон, затем знак вопроса и далее любую функцию для поверки, которая возвращает True или False. В том числе можно создать свою функцию:

less10Q[x_] := x < 10

MatchQ[10, _?less10Q] (* => False *)
MatchQ[9,  _?less10Q] (* => True  *)

Во время определений функций проверка шаблона используется так:

func[x_?less10Q] := "меньше 10"
func[___]        := "все остальное"

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

f[x_?NumericQ]     := "это оно из 4 типов чисел или численных констант"
f[x_?NumberQ]      := "только числа"
f[a_?ListQ]        := "любые списки"
f[a_?ArrayQ]       := "списки чисел"
f[a_?MatrixQ]      := "матрицы"
f[a_?StringQ]      := "строки"
f[a_?Positive]     := "положительные числа"
f[a_?IntegerQ]     := "целые"
f[a_?AssociationQ] := "ассоциации"

Условие

Есть еще один способ повторить ограждающую конструкцию в более понятном виде - это функция Condition (/;):

f[x_, y_] /; x < y  := y - x
f[x_, y_] /; x >= y := x - y

Выше мы всегда вычитаем из большего меньшее. Само условие накладывается между знаками /; и :=. В общем-то с любыми переменными можно делать все что угодно и вернуть True или False. Шаблон сматчится если вернется True и не сматчится - если что-то другое. Примечательным фактом является то, что условие можно поместить внутрь шаблона или после определения. Т.е. тоже самое можно записать вот так:

f[{x_, y_} /; x < y] := y - x
f[x_, y_]            := y - x /; x < y

Дословное сопоставление

Вот мы и дошли до одной из самых интересных глав этой статьи. Как я говорил в самом начале - все в Wolfram Language является выражением. В том числе паттерны. Это значит, что я могу присвоить переменной выражение, которое является шаблоном:

myPattern = _ 

А дальше я могу использовать его в любых целях. В матчинге:

MatchQ[x, myPattern] (* => True *)

Для выбора значений:

Cases[{{1, 2, 3}, f[4, 5, 6]}, f[myPattern, __]] (* => {f[1, 2, 3]} *)

И для создания определений:

f[x: myPattern] := x + 1

f[1] (* => 2 *)

Но тут возникает резонный вопрос. Вот есть у меня выражение:

expr = f[g[x, y], z]

Я могу заменить в нем часть вот так:

expr /. f[args___] :> f2[args] (* => f2[g[x, y], z] *)

Что произойдет, если я попробую заменить часть паттерна? Или я захочу убрать из выражения ТОЛЬКО паттерн заменив его конкретным выражением? Например ниже я хочу из списка заменит f[___] на f[x, y, z], а все остальное оставить:

{f[1, 2, 3], f[___], f[]} /. f[___] :> f[x, y, z]

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

{f[1, 2, 3], f[___], f[]} /. f[Verbatim[___]] :> f[x, y, z]

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

Ну и реальный пример использования. Я использовал эту функцию для создания API. Пусть у нас есть сервер, который работает на WL. Мы делаем запрос по HTTP:

GET /api/myFunc?n=4&x=1&y=2 HTTP/1.1

И предполагаем, что на стороне сервера будет вызвана функция:

myFunc[x_Real, y_Real, n_Integer] := x^n + y^n
myFunc[x_Real, y_Real] := x + y

Определений два, но должно выбраться то, которое содержит три аргумента по именам:

myFunc[1.0, 2.0, 4] (* т.е. myFunc[x, y, n] *)

Собственно, как это сделать? Сначала нужно разобрать пришедший запрос вот так:

parseRequest[path_String] := 
Module[{parsed, func, params}, 
  parsed = URLParse[path]; 
  func = ToExpression[parsed[["Path", -1]]];
  params = <|parsed["Query"]|>; 
  {func, params}
]

req = parseRequest["/api/myFunc?n=4&x=1&y=2"] 
(* Out[]= {myFunc, <|"n" -> "4", "x" -> "1", "y" -> "2"|>} *)

Теперь мы можем вычислить сколько должно быть аргументов у функции:

Length[req[[2]]] (* => 3 *)

Выберем только те определения, которые подходят по числу параметров:

def = Cases[DownValues @@ {req[[1]]}, 
   _[_[_[args___]], _] /; Length[{args}] == Length[req[[2]]]
][[1]]

(* HoldPattern[myFunc[x_Real, y_Real, n_Integer]] :> x^n + y^n *)

Если бы их было несколько - пришлось бы еще чуть-чуть повозиться, но мы сразу получили один шаблон, поэтому я не буду показывать как выбирать определение по именам в общем случае. Теперь при помощи замены вытащим из него определение и типы аргументов и в зависимости от типа мы преобразуем аргумент в целое число с помощью Round или в действительное при помощи N:

holdExpr = ((def[[1]] /. HoldPattern -> Hold) /. {
   Verbatim[Pattern][name_, Verbatim[Blank[Real]]] :> N[name], 
   Verbatim[Pattern][name_, Verbatim[Blank[Integer]]] :> Round[name]
   }) 
(* Out[] = Hold[myFunc[N[x], N[y], Round[n]]] *)

Остался последний шаг. Заменить переменные и выполнить функцию:

result = holdExpr /. 
 KeyValueMap[ToExpression[#1] -> ToExpression[#2] &, req[[2]]]

(* Out[] = Hold[myFunc[N[1], N[2], Round[4]]] *)

ReleaseHold[result]

(* Out[] = 17. *)

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

Удерживание

Еще одна очень интересная тема в языке - возможность удержать выражение от вычислений. Любому символу в языке можно присвоить атрибут из семейства Hold*. Например, HoldAll, HoldFirst или HoldRest. Установка атрибутов:

SetAttributes[myFunc, HoldAll]

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

anyFunc[1 + 1, 2 + 2] (* => anyFunc[2, 4]        *)
myFunc[1 + 1, 2 + 2]  (* => myFunc[1 + 1, 2 + 2] *)

Наличие атрибута замораживает все, что находится в теле выражения, если заголовок имеет Hold-атрибут. Значит мы можем абсолютно любое выражение взять в его исходном виде и проанализировать или разобрать. Причем здесь шаблоны? Я снова повторю, что все шаблоны - это тоже выражения. А значит в языке существуют функции, которые могут их преобразовать. Причем даже те, которые мы использовали выше. Простейший пример такого преобразования ниже:

_ + _ (* => 2 * _ *)

То есть сложив два подчеркивания мы просто получили символьное произведение 2 * _. Гениально!

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

{1, 2, 3, 4 -> 5, 6,  7} /. x_ -> y_ -> f[x, y]

Что же тогда делать? Естественно применить HoldPattern:

{1, 2, 3, 4 -> 5, 6,  7} /. HoldPattern[x_ -> y_] -> f[x, y]

(* Out[] = {1, 2, 3, f[4, 5], 6, 7} *)

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

Определения

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

x = 10; 

OwnValues[x] (* {HoldPattern[x] :> 10}} *)

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

MatchQ[Hold[x], HoldPattern[_Symbol]]

Следующее хранилище - это DownValues. Т.е. нисходящие значения. Его смысл в том, что оно привязано к символу и хранит те шаблоны, которые должны сопоставлять все конструкции вида:

f[x_, y_, z_] := {x, y, z}

MatchQ[Hold[f[x, y, z]], HoldPattern[_Symbol[___]]]

Т.е. конструкции вида символ + тело выражения, которое находится ниже в синтаксическом дереве. Затем идет SubValues. Матчится со всем вида символ + несколько тел ниже в синтаксическом дереве:

f[x_][y_][z_] := {x, y, z}

MatchQ[Hold[f[x][y][z]], HoldPattern[_Symbol[___][___][___]]]

Ради справедливости я должен сказать, что создать способ сопоставления с SubValues - не самая простая задача, хоть и вполне реальная. По умолчанию шаблона, который будет матчится с двумя и более квадратными скобками по соседству в WL нет.

И последнее. Это UpValues, т.е. значения по восходящей. Они соответствуют определениям вида:

f /: g[f[x_, y_, z_]] := {x, y, z}

UpValues[f]

MatchQ[Hold[g[f[x, y, z]]], HoldPattern[_Symbol[___, _Symbol[___], ___]]]

Это хранилище предназначено для переопределения существующих функциях на конкретных символах и выражениях.

Собственно вот и все наиболее важные хранилища определений. Подробное рассмотрение *Values и других хранилищ заслуживают отдельной статьи. Самое главное, что я хотел отметить - это то, что все эти списки правил хранят в себе шаблоны. Каждый раз когда ядро WL встречает любое выражение - оно начинает поиск в списках значений и сопоставляет выражение с сохраненным образцом. При успешном сопоставлении в выражении происходит замена с использованием шаблона и правил - ровно тоже самое, что было в разделе связывание. Таким образом абсолютно любой код на WL неявно использует паттерн-матчинг, о чем я говорил в самом начале.

Ну и в последний раз - реальный пример из пакета Objects, который я активно использую во множестве проектов. Код, который позволяет реализовать наследование типов. Ниже использование Language`ExtendedFullDefinition заменяет собой Own/Down/Sub/UpValues:

Заключение

В первую очередь хочу поблагодарить всех, кто дочитал до этого раздела. После прочтения у вас может сложиться впечатление, что язык Wolfram слишком сложен и перегружен. А ведь я рассмотрел только часть возможностей WL выбрав по несколько примеров из каждой важной области синтаксиса. Но я ни в коем случае не призываю бросаться с головой в шаблоны и начинать использовать их везде, где только можно в как можно более вычурном виде. Спустя много лет написания кода на WL я сам постепенно пришел стилю программирования, в котором стараюсь использовать по минимуму запутывающих конструкций. Но я все еще постоянно использую шаблоны, так как очень часто они позволяют в декларативном стиле описать что делает функция даже без определения. Затем такой код намного легче читать и проверять. Все бывает полезно в меру. Моя основная цель здесь - познакомить вас со всем многообразием возможностей языка, а что из многообразия применять в своем коде - уже ваше решение, уважаемые читатели.

Всем спасибо за внимание!