Исторически, PM использоваться начал в языках с динамической типизацией. В Prolog, Refal, Mathematica, Racket/Nanopass, Stratego, oMeta и других подобных языках PM гораздо мощнее с выч. точки зрения, чем в популярных сегодня ЯП со статической типизацией. Но авторы статических PM-вариантов, безусловно, стараются извлекать выгоду из ограничений. При этом новое поколение разработчиков, которое в глаза не видело перечисленных мной выше языков, считает эти ограничения единственно правильным вариантом реализации PM. Моя мысль в том, чтобы не пытаться смешивать возможности динамического и статического вариантов PM.

При определении функций - да. Однако, ?identifier применяется для введения идентификаторов в любых контекстах, включая`?r = f (a, b)` непосредственно в коде.

Золотые слова. Тут надо еще напомнить, что в динамических языках PM во многом замещает ту роль, которую выполняют статические типы. В типичной программе на Erlang, например, PM используется повсюду чтобы вводить имена компонентов структур данных, которые функции передают друг другу, так как нет именованых типов, которые задавали бы имена для компонент структур данных.

Да, именно!

Я был призван на холивар по pattern-matching-у с:

Во-первых, чисто для полноты картины хотел бы упомянуть Scala
Там шаблон-переменная от рантайм-константы синтаксически отличается одним из 3-мя способов:
1) По регистру первой буквы: шаблон начинается с маленькой буквы, константы с большой. По-моему элементарное лексическое правило, не запутаешься
Поэтому, например, в стандартной библиотеке Scala математические константы определены с большой буквы

import math.{Pi, E}

...
number match {
  case Pi => ...
  ...

2) Используя bactick-экранирование

val pi = Pi
E match {
  case `pi` => // not this
  case  _   => // this
}

3) Если константа является полем, можно указать путь

number match {
  case this.pi => ....
}

Выглядит довольно просто

Во-вторых, лично я, если честно, в принципе не вижу в этом никакой проблемы
А вот в том, что в Kotlin-е нет pattern-matching-а, вижу с:
Тут дело даже не во вкусах или парадигме
Конструкция сопоставления с образцом
1) Очень выразительна и легко читаема
2) Компилируется значительно эффективнее, чем аналогичные if-else разборы
3) Повышает безопасность программ благодаря exhaustiveness checking
4) К счастью, или сожалению, но для тех же скалистов, например, сопоставление с образцом стало настолько привычной и необходимой операцией, что в язык без этого они не пойдут. И многие новички могут предпочесть Скалу Котлину из подобных соображений. Поймите меня неправильно, я ни в коем случае не разжигаю холивар между сообществами, но с моей точки зрения, не включая в язык подобные инструменты, Вы сознательно ограниваете серьезную часть аудитории, причем какую — в Скалу идут самые дотошные и принципиальные разработчики. С одной стороны, там поэтому жесть как токсично, но с другой, сторонних библиотек несметное множество и их уровень высочайший. И вот по моему мнению это серьезный пункт, угрожающий мечте об одном универсальном языке программирования. Люди по-прежнему будут идти в Скалу, считая ее обладающей более мощными средствами, а Котлин рискует так и остаться языком для Андроида, ака Swift сейчас для IOS.
5) А есть альтернативы? У паттерн-матчинга изъянов множество, но они все известны. И в выборе между ним, и вообще без него, большинство все-таки предпочитает первое (ну судить хоть по тенденции последних лет — Java, C#, C++, Swift все в том или ином объеме движутся в эту сторону).

/me специально перечитал название чата — вроде бы не про Kotlin. Поэтому предметно можно дискутировать по пункту 2 " Компилируется значительно эффективнее, чем аналогичные if-else разборы". :)

P.S. Вы серьезно агитируете _компиляторщиков_ за PM? :)

тут в локальной эхе проскочило удачное название для системы программирования — "метакисель"
кто что может вспомнить из существующих, что можно так называть (кроме Лиспов)?

Brainfuck?

Справедливо, я как всегда разошелся. Очень уж переживаю по этому поводу с:
Про exhaustiveness checking тоже можно, и про то, что она в той же скале отваливается, сделай хоть шаг влево/вправо от чего-нибудь простейшего

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

Не всегда и не везде, как и со всем, но в случае с обычным switch (aka сопоставление с образом для бедных), компилятор просто генерирует код перехода по меткам.

код перехода по меткам по условию — хм, чем это отличается от иф-елсе? ну т/е понятно в некоторых случаях свитч можно в джамп тейбл — но это не про пм

В этом случае ничего эффективнее и не придумаешь :)

Оптимизация достигается уже в более серьезных видах ПМ, позволяющих вложенные образцы
И там грубо говоря оптимизация происходит за счет использования информации о типах-суммах (сюда же exhaustiveness checking) и уже разобранном префиксе образца
Например, пусть вот мы находимся сейчас в какой-то ветке и уже что-то разобрали, а что-то сломалось
И использую всю имеющуюся информацию о ветках и используемых в них типах, компилятор вставляет дополнительные прыжки, которые перемещают сразу в ту ветку и ту конкретную ее часть, где либо префикс гарантированно такой же, а то что сломалось проверяется уже по новому условию, либо, если то, что сломалось проверять уже не с чем, пытаемся немножко уменьшить префикс и найти следующую подходящую ветку
В общем там минимизируется количество заведомо проигрышных тестов и необходимость по два раза проверять одно и то же
И все это в условиях, что какие-то ветки можно переставлять, какие-то нет
По сравнению с if-else, это как если можно было сразу через несколько блоков else прыгнуть, заведомо зная, что они провалятся, а когда найдешь нужный, сразу перейти через несколько внутренних вложенных if-ов, заведомо зная, что они выполнятся

На пальцах у меня как-то плохо получается объяснить :(
Более того, там в каждой схеме компиляции свои фишки используются

А ваш пм быстрее или медленнее простых иф-елзе в итоговом бинаре?

ПМ в общем случае нельзя заменить на простые ифы

Дак быстрее, про то и говорю с:
Я, например, могу привести данные из OCaml
Там правда давняя статья, 2001 года
Но когда они добавили все свои оптимизации, они подняли производительность на 30-40%

ну как так можно? типы — это не только запреты, но и дополнительная информация

Да, ровно благодаря ним, а именно тому факту, какие конструкторы уже были разобраны, а какие остались (или никаких не осталось), в моем примере и достигается оптимизация с прыжками сразу куда надо

На ифы + goto можно

Можно написать пасс, который будет делать подобную оптимизацию для if. Да и любую другую, вроде "вместо if со сравнением строк вставить проверку по хэш-таблице". Только несколько затратнее по сложности кода этого пасса (относительно более простых оптимизаций в switch/match) и скорости компиляции.