Итак, сопоставление с образцом в функциональных языках - это довольно круто. Мне интересно, почему в большинстве императивных языков не реализована эта функция? Насколько я понимаю, Scala - единственный «основной» императивный язык, в котором есть сопоставление с образцом. Структура корпуса / переключателя намного менее мощная.
В частности, меня интересует, вызвано ли отсутствие сопоставления с образцом техническими или историческими причинами?
Это в основном историческое. Сопоставление с образцом - а точнее, алгебраические типы данных - было изобретено примерно в 1980 году для функционального языка Hope. Оттуда он быстро превратился в ML, а позже был принят на других функциональных языках, таких как Miranda и Haskell. В господствующем императивном мире обычно требуется на несколько десятилетий больше, чтобы уловить новые идеи языка программирования.
Одна из причин, по которой принятие особенно затруднено, заключается в том, что в мейнстриме долгое время доминировала объектно-ориентированная идеология. В этом мире все, что не выражается объектами и подтипами, считается морально «неправильным». Можно утверждать, что алгебраические типы данных являются своего рода противоположностью этому.
Возможно, есть также некоторые технические причины, которые делают его более естественным на функциональных языках:
Регулярные правила определения области видимости и детализированные конструкции привязки для переменных являются нормой для функциональных языков, но менее распространены в основных императивных языках.
Тем более, что шаблоны связывают неизменяемые переменные.
Соответствие шаблонов проверки типов основано на более хорошо сформированной структуре и жесткости систем функциональных типов, а также их тесной связи с вычислительной логикой. Системы массового типа обычно далеки от этого.
Алгебраические типы данных требуют выделения кучи (если вы не хотите тратить много места и запрещать рекурсию) и были бы очень неудобны без сборки мусора. Однако сборщики мусора на основных языках там, где они существуют, обычно оптимизированы для тяжелых объектов, а не для легких функциональных данных.
if, case или switch. AFAII, это был роман в «Надежде».
- person Andreas Rossberg; 23.06.2016
До недавнего времени (точнее: до Scala) считалось, что сопоставление с образцом несовместимо с незнанием представления (т.е. определяющей характеристикой объектно-ориентированного программирования). Поскольку объектно-ориентированный подход является основной парадигмой в основных языках, наличие кажущейся несовместимой особенности в основных языках, по-видимому, не имело смысла.
В Scala сопоставление с образцом согласуется с объектно-ориентированным подходом просто за счет того, что операции сопоставления являются вызовами методов объекта. (Задним числом довольно просто, не так ли?) В частности, сопоставления выполняются путем вызова методов для объектов-экстракторов, которые, как и любой другой объект, имеют доступ только к общедоступному API исследуемого объекта, таким образом не нарушая инкапсуляцию.
Библиотека сопоставления с образцом, вдохновленная Scala, в которой образцы сами по себе являются первоклассными объектами (вдохновленные активными образцами F #), была добавлена в новояз, очень динамический язык, который требует OO очень серьезно. (В новоязе нет даже переменных, только методы.)
Обратите внимание, что регулярные выражения являются примером ограниченной формы сопоставления с образцом. Отправку полиморфного метода также можно рассматривать как пример ограниченной формы сопоставления с образцом (без функций извлечения). Фактически, диспетчеризация методов достаточно мощна для реализации полного сопоставления с образцом, о чем свидетельствует Scala и особенно новояз (в последнем сопоставление с образцом даже реализовано как библиотека, полностью отделенная от языка).
Вот мои 2 цента. Возьмем простое совпадение Option с шаблоном:
val o = Some(1)
o match {
case Some(i) => i + 1
case None => 0
}
В Scala происходит так много всего. Компилятор проверяет, есть ли у вас полное соответствие, создает новую переменную i для области действия оператора case и, конечно же, каким-то образом извлекает значение из Option.
Извлечь значение можно на таких языках, как Java. Реализуйте unapply методы некоторого согласованного интерфейса, и все готово. Теперь вы можете возвращать значения вызывающему.
Предоставление этого извлеченного значения вызывающей стороне, что по существу требует закрытия, не так удобно в обычных объектно-ориентированных языках без поддержки закрытия. Это может стать довольно уродливым в Java7, где вы, вероятно, использовали бы шаблон Observer.
Если вы добавите в смесь другие возможности Scala по сопоставлению с образцом, например сопоставление по определенным типам, то есть case i: Int =>; используя предложение по умолчанию _, когда вы хотите (компилятор должен каким-то образом проверять полноту, используете ли вы _ или нет); дополнительные проверки типа case i if i > 0 =>; и так далее он быстро становится очень уродливым для использования со стороны клиента (подумайте о Java).
Если вы отбросите все эти причудливые функции сопоставления с образцом, сопоставление с образцом будет в значительной степени на уровне оператора Java switch.
Похоже, что просто не стоит, даже если это возможно, реализовывать с использованием анонимных классов без поддержки лямбда-выражений и строгой системы типов.
Я бы сказал, что это больше по историческим, чем по техническим причинам. Сопоставление с образцом хорошо работает с алгебраическими типами данных, которые также исторически ассоциировались с функциональными языками.
Scala, вероятно, является плохим примером императивного языка с сопоставлением с образцом, потому что он склонен отдавать предпочтение функциональному стилю, хотя и не навязывает его.
Примером современного, в основном императивного языка с сопоставлением с образцом является Rust. Императивен и работает на металле, но по-прежнему имеет алгебраические типы данных, сопоставление с образцом и другие функции, более общие для функциональных языков. Но его реализация компилятора намного сложнее, чем у компилятора C.
