Почему Haskell заставляет первую букву конструктора данных быть заглавными? - PullRequest
20 голосов
/ 04 июня 2011

Приведите ужасный пример:

data Bighead = Big

little = 1 

f1 = little :: Int

f2 = Big :: BigHead

На мой взгляд:

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

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

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

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

Является ли это единственной причиной того, что Haskell по-разному обрабатывает данные и имена функций?

Позвоните для анализа: -)

редактировать: еще несколько пэдов

data A = B Int

тип B:

B :: Int -> A

b :: Int -> A

b = B 

Ответы [ 3 ]

30 голосов
/ 04 июня 2011

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

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

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

Итак, учитывая, что мы делаем , чтобы отличать конструкторы от переменных, возникает вопрос «почему?».

Чтение типов

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

Сопоставление с образцом

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

case x of
   Foo y z -> ...

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

g (f (Foo 1 2)

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

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


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

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

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

Haskell B

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

12 голосов
/ 04 июня 2011

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

f (Foo bar) Baz bay = bar + bay

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

2 голосов
/ 08 июня 2011

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...