Подтвердить что ты не робот

Почему Haskell заставляет конструктор данных первой буквы быть верхним регистром?

Дайте уродливый пример:

data Bighead = Big

little = 1 

f1 = little :: Int

f2 = Big :: BigHead

По-моему:

f1 и f2 все указывают на некоторые данные. единственными отличиями (little и Big) являются у маленького кода есть код для оценки. но Big не делает.

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

Но в синтаксической форме они почти одинаковы: их можно применять, их можно оценить.

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

Это единственная причина, по которой Haskell рассматривает имена данных и функций по-разному?

Вызов для анализа: -)

изменить: еще несколько прокладок

data A = B Int

тип B:

B :: Int -> A

b :: Int -> A

b = B 
4b9b3361

Ответ 1

Из Haskell 98 Language мы видим основное различие в токенах идентификатора в Haskell:

varid   ->   (small {small | large | digit | ' })<reservedid>
conid   ->   large {small | large | digit | ' }

Таким образом, язык принципиально отличает имена переменных ( "varid" ) от имен конструкторов ( "conid" ) на всех уровнях языка (как значения, так и переменные типа и конструкторы). Таким образом, Haskell выделяет идентификаторы на два основных пространства имен (ну, есть и другие, если вы считаете модули и классы), но два основных, те, которые начинаются с буквы нижнего регистра (переменные идентификаторы) и те, которые начинаются с верхнего -case letter (идентификаторы конструктора).

Итак, учитывая, что мы различаем конструкторы от переменных, вопрос "почему?".

Типы чтения

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

Соответствие шаблону

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

case x of
   Foo y z -> ...

Вы знаете, что Foo - это разделяемая структура данных и названные ее компоненты. Соответственно, всякий раз, когда вы видите идентификатор верхнего регистра в выражении,

g (f (Foo 1 2)

вы знаете, что f получает новый тип данных Foo с двумя аргументами.

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


Пространства имен

В Haskell существует шесть типов имен: те, для переменных и конструкторов, обозначают значения; те, для переменных типа, конструкторы типов и классы типов относятся к объектам, относящимся к системе типов; и имена модулей относятся к модулям. Существует два ограничения на именование:

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

Haskell B

В Haskell B конструкторы и переменные могут использовать любой случай.

Ответ 2

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

f (Foo bar) Baz bay = bar + bay

Здесь Haskell знает, что Foo и Baz являются конструкторами, которые должны соответствовать, и bar и bay являются переменными, которые он должен ввести из-за того, как они капитализируются.

Ответ 3

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

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

--- Абельман и Суссман, структура и интерпретация компьютерных программ

Любой дурак может написать код, который может понять компьютер. Хорошие программисты пишут код, который люди могут понять.

--- Мартин Фаулер