Мотивация для Scala подчеркивания в терминах теории формального языка и хорошего стиля?

Почему многие говорят, что использование подчеркивания - хорошая практика в Scala и делает ваш код более удобочитаемым? Говорят, что мотивация исходит из формальной теории языка. Тем не менее многие программисты, особенно с других языков, особенно те, которые имеют анонимные функции, предпочитают не использовать подчеркивания, особенно для заполнителей.

Итак, в чем смысл подчеркивания? Почему символ Scala (и некоторые другие функциональные языки, обозначенные om-nom-nom) имеют знак подчеркивания? И что такое формальное подкрепление, с точки зрения сложности и теории языка, почему часто используется хороший стиль?

Ответ 1

Лингвистика

Источником и мотивацией для большей части подчеркивания, используемого в Scala, является возможность создания выражений и деклараций без необходимости всегда давать каждую переменную (я имею в виду "переменную", как в исчислении предикатов, а не в программировании) язык имени. Мы используем это все время на естественном языке, например, я упомянул концепцию в предыдущем предложении в этом предложении, используя "this", и я упомянул это предложение, используя "this", не имея никакой путаницы в отношении того, что я имею в виду. В естественном языке эти слова обычно называются "сильные" местоимения "," anaphors "," катафоры ", референты" антецедент "или" postcedent ", а процесс их понимания/разыменования называется" anaphora ".

Теория алгоритмической информации

Если бы нам пришлось называть все "вещи" на естественном языке, прежде чем мы можем ссылаться на него, одинаково каждый тип вещи, чтобы количественно оценить его, как в исчислении исчисления и в большинстве языков программирования, тогда говорить было бы очень долго многословно. Благодаря контексту мы можем заключить, что подразумевается под словами типа "this", "it", "that" и т.д., Мы делаем это легко.

Поэтому зачем ограничивать это простое, элегантное и эффективное средство общения с естественным языком? Поэтому он был добавлен в Scala.

Если мы пытались назвать каждую "вещь" или "тип вещи", предложения становятся настолько длинными и сложными, что становится очень трудно понять из-за этого многословия и введение избыточных символов. Чем больше символов вы добавляете к предложению, тем труднее становится понимать, эрго именно поэтому это хорошая практика не только на естественном языке, но и в Scala. На самом деле можно было бы формализовать это утверждение с точки зрения сложности Колмогорова и доказать, что последовательность предложений, принимающих заполнители, имеет более низкую сложность, чем те, которые излишне называют все (если только имя не является точно таким же в каждом случае, но это обычно не имеет смысла). Поэтому мы можем окончательно сказать, вопреки мнению некоторых программистов, что синтаксис placeholder проще и легче читать.

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

Примеры

Теперь рассмотрим некоторые конкретные применения более формально:

Синтаксис заполнителя

Означает "это", "их", "это", "их" и т.д. (т.е. местоимения), например. 1

lines.map(_.length)

можно читать как "линии карты по их длине", аналогично мы можем читать lineOption.map(_.length) как "сопоставить линию с ее длиной". В терминах теории сложности этот проще, чем "для каждой строки" в строках, занимает длину "строка" - это будет lines.map(line => line.length).

Также может быть прочитан как "the" (определенная статья) при использовании с аннотацией типа, например

(_: Int) + 1

"Добавить 1 в целое число"

Экзистенциальные типы

означает "какого-то типа" ( "некоторое" местоимение), например

foo: Option[_]

означает, что "foo является опцией некоторого типа".

Параметры более высокого качества

Опять же, в основном означает "какого-то типа" ( "некоторое" местоимение), например

class A[K[_],T](a: K[T])

Может быть прочитано "класс A берет некоторый K некоторого типа..."

Подстановочные знаки соответствия шаблонов

Значит "что угодно" или "что угодно" (местоимения), например

case Foo(_) => "hello"

может быть прочитан как "для Foo, содержащего что-либо, верните" привет "или" для Foo, содержащего что угодно, верните "привет"

Импортировать подстановочные знаки

означает "все" (местоимение), например

import foo._

можно прочитать как "импортировать все из foo".

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

Теперь я прочитал это как "a" (неопределенная статья), например

val wine: RedWine = _

"Дай мне красное вино", официант должен дать тебе дом красный.

Другие применения подчеркивания

Другие использования символов подчеркивания на самом деле не связаны с точкой этого Q & A, тем не менее мы кратко обсуждаем их

Игнорируемые значения /Params/Extractions

Позвольте нам игнорировать вещи в явном "безопасном шаблоне". Например.

val (x, _) = getMyPoint

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

Хранение импорта

Только способ сказать "за исключением" (предлог).

Назначение функций

например.

val f: String => Unit = println _

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

Использовать в специальных именах методов

Чисто синтаксическая вещь и на самом деле не связана с лингвистикой.