Лучше использовать «и» или «in» при цепочке операторов «Let»?

Question

Я понимаю, что это, вероятно, глупый вопрос, но ...

Если я собираю кучу let заявления, которые делают нет нужно знать значения друг друга, лучше ли использовать and или же in?

Например, что из них предпочтительнее, если таковые имеются:

let a = "foo"
and b = "bar"
and c = "baz"
in
  (* etc. *)

или же

let a = "foo" in
let b = "bar" in
let c = "baz"
in
  (* etc. *)

Моя интуиция говорит мне, что прежнее должно быть «лучше» (по очень мелкому определению «лучше»), потому что это создает минимальное количество необходимых областей, тогда как последнее-это область применения с помощью Scope-a-a- Область, которую компилятор/интерпретатор заботится, но в конечном итоге является неважным и излишне глубоким.

Answer 1

Ответ на вопрос "Что лучше?" На самом деле имеет смысл, только когда интерпретации не различаются. Семейство языков ML (по крайней мере, SML и OCAML) имеют как форму параллельной инициализации (and) и последовательная, по существу вложенную форму (in) потому что они оба полезны в определенных ситуациях.

В вашем случае семантика такая же, поэтому вам остается ответить на вопрос «Что вам лучше всего читает?» И, может быть, (если это не преждевременно) «что может быть выполнено более эффективно?» В вашем случае альтернативы:

• Для and Случай: оценить кучу струн и сделать параллельное связывание с тремя идентификаторами.

• Для in Случай: привязка foo к a, тогда связывать bar к b, тогда связывать baz к c.

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

Что касается того, что выполняется более эффективно, я думаю, что хороший компилятор, вероятно, будет производить тот же код, поскольку он может обнаружить порядок связывания, не будет иметь значения. Но, возможно, у вас есть компилятор, который генерирует код для многоядерного процессора, который лучше справляется с and. Анкет Или, может быть, наивный компилятор, который записывает все RHS во временное хранение, а затем связывает их, делая and дело медленнее.

Это, вероятно, будут несущественными проблемами оптимизации, особенно потому, что они связаны с привязками и, вероятно, не находятся в тесных петлях.

Итог: это истинный в этом случае подбрасывание; Просто убедитесь, что правильно используйте параллельные и последовательность, когда результат имеет значение.

Answer 2

Мое мнение в том, что in это лучше. Использование and Подразумевает, что определения взаимно зависят друг от друга. Я думаю, что лучше быть ясным, что это не так. С другой стороны, некоторые программисты OCAML предпочитают and Для очень коротких определений, где немного более компактная нотация может показаться чище. Это особенно верно, когда вы можете установить определения на одной строке:

let a = "foo" and b = "bar" in

Answer 3

Это то же самое, что разница между let а также let* В LISP, я верю.let* (аналогично функциональности для in..in.. Структура - вторая структура в вашем вопросе) иногда используется для скрытия императив программирование с тех пор, как оно гарантирует последовательное выполнение выражений (посмотрите, что Пол Грэм должен был сказать о Let* in На LISP).

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

Answer 4

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