Основные вопросы F #: изменчивость, стандарты капитализации, функции и методы

Question

Не стесняйтесь указывать мне другие ответы, если они уже были заданы!

Я только начинаю F # с новым выпуском в этом месяце. У меня есть некоторый опыт работы с ОО и функциональными языками (Haskell и Scheme, но не OCaml / ML). Пара вопросов возникла так далеко от прочтения небольшого учебника, который поставляется с F # CTP.

1) Являются ли изменяемые переменные предпочтительнее монад? Если так, монады полностью избегают в F #?

2) Меня немного смущает использование заглавных букв. В этом учебном кодовом файле иногда функции начинаются со строчной буквы, а иногда с заглавной буквы. Я знаю, что MS имеет тенденцию любить начальные заглавные буквы с функциями и методами, но здесь кажется, что есть два способа сделать это. Для меня это не большое дело, так как я просто играю в свое свободное время, но мне любопытно, каков стандарт.

3) Я довольно озадачен всей этой комбинацией ОО и функциональных стилей. print_string "string" имеет смысл, но тогда вот List.map fn list (если List не является просто пространством имен, простите, если так). Тогда вот str.Length. Кто-нибудь хочет выяснить, когда и что использовать, и что является предпочтительным?

Спасибо!

Answer 1

1) Я бы не сказал, что монады избегают ... Вы упомянули, что у вас есть некоторый опыт работы с Haskell - поэтому рабочие процессы F # - это то, что вы хотите рассмотреть (термин рабочий процесс может сбивать с толку, но это только чуть-чуть, чтобы сделать с бизнес-процессами). В общем, выражения последовательности и, в более общем случае, вычислительные выражения (рабочие процессы a.k.a) будут близки к монадам. При этом изменчивость встречается довольно часто, хотя я не уверен, что «предпочтение» - это способ выразить это. У каждого из них есть место - Лично я начал с двух книг - «Основы F #», - но если вы хотите погрузиться в это, - «Эксперт F #» - обе хороши. Честно говоря, мне нужны были Фонды, чтобы помочь мне начать.

2) По моему опыту, путаница заключается в том, что традиционные функции в .NET имеют соглашение, которое действительно не поддается функциональному программированию. Таким образом, я чувствую, что в F # у вас может возникнуть путаница, когда вы смотрите на использование «традиционных .NET» именованных функций и элементов F #, которые явно функциональны ... Например, в книге, которую я упоминал выше «Эксперт F #» - они упоминают, что вы увидите значения let, такие как List.map и Dates.Today в camelCase и PascalCase (Pascal - более традиционный .NET). Хорошее практическое правило заключается в том, что если вы остаетесь в функциональном мире - используйте более традиционные функциональные (camelCase) именования - однако, если то, что вы делаете, предполагается использовать в других языках .NET, используйте больше .NET норма (Паскаль). Также обратите внимание, что в функциональном мире существует гораздо более высокий допуск к аббревиатурам (itr, tbl и т. Д.), Когда .NET в целом отошел от этого ... Итак, еще раз, вы увидите различную степень этого в некотором роде, если вы называете функциональные элементы против элементов, представленных в F #, которые являются общими для всего .NET.

3) Я согласен, что сочетание ОО и стилей функций может сбивать с толку. Опять же, я не уверен, что предпочтительнее, за исключением того, что F # (будучи функциональным) явно стилизует себя с точки зрения функциональной парадигмы. Однако F # - это функциональный язык в мире .NET (обратите внимание на относительную путаницу имен, о которой я упоминал выше) ... Итак, опять же, это не совсем ясно.

Надеюсь, это поможет ... Верьте или нет, если вы используете F # и думаете о других языках, которые имеют общие концепции C ++ с C (например) - это становится проще. Лично, присвоение имен стало иметь смысл, и концепции сработали, когда я начал понимать, что я являюсь F # - это функциональный язык, работающий на традиционной платформе, созданный для взаимодействия (хотя я не уверен, что было бы целесообразно называть взаимодействие бесшовным: D)

Answer 2

Относительно изменчивости: F # позволяет вам быть прагматичным. Я редко предпочитаю монаду состояния изменчивому / реф, но вы можете делать все, что захотите. Монады не избегают, но я думаю, что люди склонны использовать их только тогда, когда они явно выигрывают (например, асинхронное программирование).

Относительно именования: существует напряженность в том факте, что «функции являются значениями» означает, что вы можете выбрать функцию с привязкой к имени с большой буквы (потому что это функция, а функции начинаются с заглавных букв) или с более низкой -case буква (потому что это значение с привязкой к букве (в названии типа просто есть '->')). Лично я предпочитаю всегда использовать имена в верхнем регистре для всех функций, но вы увидите оба стиля (особенно потому, что стиль самой библиотеки F # медленно развивался / стандартизировался в течение последних года или двух). Подчеркивания, кажется, избегают во всем .Net, и библиотека F # больше не является исключением (осталось несколько имен, которые используют подчеркивание, но теперь они выделяются как больной большой палец и, вероятно, будут изменены).

Относительно стиля функции: мне неясно, что вы спрашиваете. В случае List.map, «List» - это имя модуля F # , а «map» - функция в этом модуле. Функции-члены (например, str.Length) имеют то преимущество, что их часто используют в .Net, и они обеспечивают приятную интеллигентную работу в редакторе.

Answer 3

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

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