Статья:
Язык Nemerle. Часть 3

Автор(ы): Чистяков Владислав Юрьевич
Дата: 25.07.2010
Неформальное введение в язык программирования Nemerle. В этой части, на базе примера «калькулятор», описываются типы данных variant и class.

Авторы:
Чистяков Владислав Юрьевич

Аннотация:
Неформальное введение в язык программирования Nemerle. В этой части, на базе примера «калькулятор», описываются типы данных variant и class.

Доброе время суток.

В статью закралась маленькая опечатка:

 def loop(firstValueOpt, tokens)
  {
    | (Some(first), Token.Operator("+") :: tokens) =>
      def plus(a, b) { a + b }
      parseOperation(first, parseMulOrDiv, tokens, plus, loop)

    | (Some(first), Token.Operator("-") :: tokens) =>
      def minus(a, b) { a + b }
      parseOperation(first, parseMulOrDiv, tokens, minus, loop)
      
    | (Some, tokens) => (firstValueOpt, tokens)
    | (None, tokens) => (None(), tokens)
  }

Операторы функции plus и minus определены одинаково

И ссылка на www.nemerle.org ведет в 404.

Здравствуйте, catbert, Вы писали:

C>И ссылка на www.nemerle.org ведет в 404.

Точнее ссылка http://rsdn.ru/article/Nemerle/www.nemerle.org

Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:

ЧВЮ>Аннотация:
ЧВЮ>Неформальное введение в язык программирования Nemerle. В этой части, на базе примера «калькулятор», описываются типы данных variant и class.

Исправь опечатку "кальуклятор" -> "калькулятор"

Здравствуйте, Denom, Вы писали:

D>Операторы функции plus и minus определены одинаково

Ага. Спасибо! Видимо последствия копипэст технологии при переносе кода в статью.

Но меня больше интересует есть ли проблемы с восприятием написанного?

Не слишком ли сложные примеры?

Как вообще читается?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Denom, Вы писали:

D>>Операторы функции plus и minus определены одинаково

VD>Ага. Спасибо! Видимо последствия копипэст технологии при переносе кода в статью.

VD>Но меня больше интересует есть ли проблемы с восприятием написанного?

У меня — нет.

VD>Не слишком ли сложные примеры?

Как по мне так в самый раз, если примеры будут совсем простые — будет плохо.
Будут фразы типа "ну это понятно, а пример из жизни?"

VD>Как вообще читается?

Читается хорошо. Изложено понятно и доступно.
Собственно мне язык из-за статей и понравился(когда только узнал о нем) — читаешь и все понятно.
Хотя у меня уже есть небольшой бэкграунд в этой области (nemerle, .net, функциональное программирование)
Может быть есть смысл дать почитать новичкам.

Здравствуйте, Denom, Вы писали:

D>Как по мне так в самый раз, если примеры будут совсем простые — будет плохо.
D>Будут фразы типа "ну это понятно, а пример из жизни?"

Собственно я из этого и исходил когда выбирал пример. Меня тоже бесит когда ФП начинают подавать на примерах типа Фибоначи, а ООП на базе дерева эволюции животных.

VD>>Как вообще читается?

D>Хотя у меня уже есть небольшой бэкграунд в этой области (nemerle, .net, функциональное программирование)
D>Может быть есть смысл дать почитать новичкам.

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

Но я потому и спрашиваю. Может все же кто-то посмелее найдется и даст ценные советы. А то в следствии того о чем говорилось выше пример получился все же не элементарным. В общем, очень сложно соблюсти баланс между простотой в плоть до банальности, и сложностью. Шаг в сторону и получается очень сложно. Шаг в другую и получается банально и не интересно. Хочется показать более менее реальные примеры, но при этом чтобы не получилось так, что большая часть неподготовленных людей отвалилась еще в самом начале.

Опечатки, знаки препинания и т.д. (ИМХО):

1) Развиваем пример «Кальуклятор»

2) Если переменная lexeme ссылается на Token.Operator, будет выполнено выражение «WriteLine(name);», и, соответственно, если переменная lexeme указывает на Token.Error, выполнится выражение «WriteLine("Ошибка ввода!");»

Отсутствуют выделенные предлог "на" и запятая перед "соответственно".

3) Переменные, введенные в образце, видны только в рамках обработчиков вхождений оператора match, то есть они видны после «=>» и до следующего образца или до закрывающей фигурной сбоки оператора match

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

Отсутствует запятая перед "чтобы".

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

Отсутствует запятая перед "чтобы".

6) Все, что делает конструктор – копирует значение параметра в поле

Отсутствует запятая перед "что".

7) Именно по этому при прочих равных условиях имеет смысл предпочитать неизменяемые поля изменяемым.

"Поэтому" должно быть написано слитно.

8) Например, для числа это будут нули.

По идее, должно быть не "будут нули", а "будет нуль". Или же "для чисел это будут нули".

9) то по умолчанию для вхождений варианта будет созданы следующие конструкторы:

Должно быть "будут созданы".

10) Nemerle поддерживает перегрузку почти для всего, чего угодно, кроме локальных функций и переменных.

Отсутствует запятая перед "чего".

11) Поэтому мы заменяем его на void-литерал «()», который, как вы, надеюсь, помните, означает «ничего не делать».

"надеюсь" нужно выделить запятыми.

12) Вторая новая возможность – это задание имени для части образца:

Я бы добавил "для" для большей понятности.

13) Скобки, в которые взята конструкция «Token.Number(0) as zeroNum», нужны для того, чтобы компилятор мог понять, к чему относится оператор «as».

Отсутствует запятая перед "чтобы".

14) И, конечно же, если ввести выражение, не содержащее ошибок, то будет выдан корректный результат:

Отсутствует запятая после "И".

15) Если в выражении вообще не присутствует сложения, то это будет единственная операция умножения «A».

Должно быть "не присутствует сложение", а лучше "отсутствует сложение".

16) Каждое сложение можно рассматривать или как единичную операцию умножения, за которой ноль или более раз идет знак «+», или "-" и еще одна операция умножения.

Возможно, лишняя запятая перед 'или "-" и еще одна операция умножения'

17) В общем-то, она уже использовалась в данном примере для получения значения символа в строке.

Отсутствует запятая после "В общем-то".

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

Согласование числа.

19) Значение индекса проверяется во время компиляции, так что невозможно передать в него значение большее, чем количество элементов в кортеже минус единица, и меньшее нуля.

Отсутствует запятая после "единица".

20) Это вычисленное значение выражения, завернутое в Some, или None в случае ошибки.

Отсутствует запятая после "Some".

21) Второй элемент кортежа, возвращаемого функцией parseSumOrSub, содержит остаток (хвост) списка, содержащего токены.

Отсутствуют запятые после "кортежа" и после "parseSumOrSub".

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

Отсутствуют запятые после "необходимость" и после "всего". Я бы еще добавил "о том" для легкости чтения.

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

Отсутствуют запятые после "Some()", после "списка" и после "параметра tokens".

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

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

25) Выделенный фрагмент дублируется с фрагментом, идущим ниже.

"c" лишнее.

26) Кроме того, он дублируется с аналогичным кодом из функции parseMulOrDiv, а исключением вызова (parseMulOrDiv), строкового литерала в образце ("+" / "-" / "*" / "/") и собственно операций, выполняемых над first и second.

"c" лишнее.

27) Фактически, данные функции нужны только для того, чтобы передать коротенькое выражение в качестве параметра другой функции.

Я бы добавил "для того" для улучшения читабельности.

28)Лямбды – это безымянная функция, объявляемая по месту.

Должно быть "лямбда" или "лямбда-функция".

29) Так, вместо того, чтобы выносить код в отдельную функцию, можно было бы просто описать вхождение оператора match, содержащее два образца и специальный оператор with:

Отсутствует запятая перед "чтобы".

30) В параметры op1 и op2 передаются строки, описывающие операторы, а в f1 и f2 - функции, соответствующие этим операторам.

Отсутствует запятая после "функции", тире перед "функции".

31) Дело в том, что функция parseSumOrSub объявлена ниже функции parseSimpleExpr, а значит, не будет в ней видна (доступна).

Отсутствует "о" в слове "Дело".


32) Не закрытая скобка

Должно быть "Незакрытая".

33) Нераспозннаый токен

34) Итак, модуль – это пользовательский тип данных (как и описанные выше вариантные типы), который позволяет описывать глобально видимые функции (называемые в .Net статическими методами).

Отсутствует запятая перед "который".

35) Скажу только, что она очень похожа на EBNF.

Отсутствует запятая перед "что".

36) DSL, очень советую прочесть англоязычное описание этого термина... оно более корректно и развернуто

Многоточие можно заменить на запятую.

37) Если вам интересна его реализация, то полный исходный код этого макроса и примеры, демонстрирующие его использование, можно найти здесь (сам макрос расположен в подкаталоге LRPEGCC).

Отсутствует запятая после "примеры".

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

Заменить "их" на "его".

Замечания по содержанию.

1) В аннотации указано, что в статье имеется введение в классы,
но в самой статье о классах говорится только, что

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

При этом в статье есть введение понятия модуля.

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

3) В разделе "Устранение дублирования кода с использованием множественных образцов" мне осталось неясно,
с чем же все-таки во входном кортеже сопоставляется переменная из ключевого слова "with".

4) Понятие перегрузки вводится два раза в тексте статьи.

5) Очень сложные и длинные предложения. Например:

Ведь в месте, где она объявляется, могут быть недоступны те данные, которые были доступны в тех местах, откуда переносится код.
Кроме того, если (как в нашем случае) выделяемых фрагментов много, и они имеют некоторые различия (в нашем случае это операторы и строковые литералы в образце), отличающиеся фрагменты кода также нужно передать в качестве параметров.
Это связано с тем, что функции div недостаточно информации, и с тем, что она не может оповестить внешнюю функцию о том, что вычисление окончилось неудачей (в результате чего даже в случае ошибки выводится результат вычисления (неверный)).
Через новый (последний) параметр будет передаваться позиция текущего токена, а оборачивание возвращаемого значения в option[] позволит сообщить вызывающей функции, что вычисление закончилось неудачей, или вернуть результат, завернутый в Some, если вычисление завершилось успешно.

Такие предложения могут быть сложны для восприятия русскоязычным читателем.
Но еще сложнее будет сделать перевод статьи на другой язык, например, на английский. При этом близкий к тексту перевод будет крайне затруднен для восприятия англоязычными читателями.
Для научной статьи это было бы терпимо, но для статьи, целью которой является продвижения Nemerle в массы, это крайне вредно.

Поэтому нужно постараться разбить длинные сложные предложения на более простые.

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

а) В содержании в начале статьи нужно убрать смешение понятий языка с процессом разработки.
Т.е. сейчас есть подразделы "Конструктор", "Модификаторы доступа", "Частичное применение",... c одной стороны.
C другой стороны есть подразделы "Подфункция loop", "Устранение дублировния", "Рефакторинг" и т.д.

Я бы разделил всю статью по более крупным подразделам, описывающим процесс разработки.
Например: "Тестирование лексера" (вынести в предыдущий раздел/статью),
"Реализация парсинга", "Улучшение диагностики ошибок", "Поддержка приоритетов операций", "Рефакторинг",
"Поддержка скобок и унарных операций", "Использование модулей".
Понятия самого языка, рассматриваемые в статье, можно перечислить в самом начале статьи (рядом с содержанием) в виде списка с ссылками на соответствующие места статьи.

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

Все ИМХО

Здравствуйте, Alex_Avr, Вы писали:

A_A>1) В аннотации указано, что в статье имеется введение в классы,
A_A>но в самой статье о классах говорится только, что

A_A>

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

A_A>При этом в статье есть введение понятия модуля.

Да, есть такое дело. Раздел про классы не удался, плюс статья превысила лимиты RSDN Magazine в котором она публиковалась. Так что я ее удалил и отложил до следующей части.

Аннотацию поправим.

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

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

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

A_A>3) В разделе "Устранение дублирования кода с использованием множественных образцов" мне осталось неясно,
A_A>с чем же все-таки во входном кортеже сопоставляется переменная из ключевого слова "with".

Переписал этот кусок следующим образом (надеюсь это будет понятнее):

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

| (Some(first), Token.Operator("+") :: tokens) with operator = _ + _
| (Some(first), Token.Operator("-") :: tokens) with operator = _ - _ =>
  match (parseMulOrDiv(tokens))
  {
    | (Some(second), tokens) => loop(Some(operator(first, second)), tokens)
    | (None, tokens)         => (None(), tokens)
  }

Если в первом случае (когда дублирующийся код выносился в функцию) абстрагирование от конкретного оператора происходило за счет передачи функции-оператора через параметр локальной функции, то в данном случае используется переменная «operator», которая вводится с помощью ключевого слова «with». Эта переменная доступна в рамках обработчика вхождения оператора match.
Обратите внимание на то, что каждый образец инициализирует переменную своим значением. Так, если значение сопоставится с образцом:

| (Some(first), Token.Operator("+") :: tokens)

то переменная «operator» будет проинициализирована значением «_ + _», а если значение сопоставится с образцом:

| (Some(first), Token.Operator("-") :: tokens)

то переменная «operator» получит значение «_ — _».
Того же самого можно было бы добиться, если вводить переменную внутри тела обработчика, но при этом потребовались бы дополнительные (дублирующие) проверки. Использование ключевого слово «with» позволяет избежать этого.
Задать тип для переменной, вводимой через «with», невозможно. Компилятор будет сам выводить их типы, исходя из типов инициализирующих выражений (идущих непосредственно за «=»). Если типы выражений различаются, компилятор попытается вывести наибольший общий тип (о том, что это означает, вы узнаете чуть позже), а если это не удастся, то компилятор выдаст сообщение об ошибке.

A_A>4) Понятие перегрузки вводится два раза в тексте статьи.

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

A_A>5) Очень сложные и длинные предложения.

A_A>Например:
A_A>

A_A>Ведь в месте, где она объявляется, могут быть недоступны те данные, которые были доступны в тех местах, откуда переносится код.
A_A>Кроме того, если (как в нашем случае) выделяемых фрагментов много, и они имеют некоторые различия (в нашем случае это операторы и строковые литералы в образце), отличающиеся фрагменты кода также нужно передать в качестве параметров.
A_A>Это связано с тем, что функции div недостаточно информации, и с тем, что она не может оповестить внешнюю функцию о том, что вычисление окончилось неудачей (в результате чего даже в случае ошибки выводится результат вычисления (неверный)).
A_A>Через новый (последний) параметр будет передаваться позиция текущего токена, а оборачивание возвращаемого значения в option[] позволит сообщить вызывающей функции, что вычисление закончилось неудачей, или вернуть результат, завернутый в Some, если вычисление завершилось успешно.

A_A>Такие предложения могут быть сложны для восприятия русскоязычным читателем.

Так "могут" или сложны? Мне кажется главное — это понятен ли смысл сказанного или нет. Прочитал эти примеры. Согласен, что длинновато. Но боюсь, что от разбиения на несколько предложений легкости чтения не прибавится. В прочем, с радостью приму предложения о том как можно их порезать без потери смысла.

A_A>Но еще сложнее будет сделать перевод статьи на другой язык, например, на английский. При этом близкий к тексту перевод будет крайне затруднен для восприятия англоязычными читателями.

Да, согласен. Перевод это усложнит.

A_A>Для научной статьи это было бы терпимо, но для статьи, целью которой является продвижения Nemerle в массы, это крайне вредно.

Согласен (особенно с аргументом о переводе), но я все же не писатель про зяек .

В общем, предлагайте — поправим.

A_A>Поэтому нужно постараться разбить длинные сложные предложения на более простые.
A_A>6) Статья очень перегружена материалом, при этом есть проблемы со структуированием.
A_A>На мой взгляд нужно бы сделать следующее.

A_A>а) В содержании в начале статьи нужно убрать смешение понятий языка с процессом разработки.
A_A>Т.е. сейчас есть подразделы "Конструктор", "Модификаторы доступа", "Частичное применение",... c одной стороны.
A_A>C другой стороны есть подразделы "Подфункция loop", "Устранение дублировния", "Рефакторинг" и т.д.

A_A>Я бы разделил всю статью по более крупным подразделам, описывающим процесс разработки.

Ну, это как раз следствие выбранной стратегии — подача материала на примерах (когда примеры идут перед тем ради объяснения чего они созданы). Простое изменение заголовков ничего не изменит. А менять суть — означает отказаться от смой идеи.

Я планирую сделать иначе. Еще одна часть будет посвящена поддержке ООП, а далее будет часть в которой будет чистый "мануал" в котором будет список фич и короткие примеры их демонстрирующие.

A_A>Например: "Тестирование лексера" (вынести в предыдущий раздел/статью),

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

A_A>"Реализация парсинга", "Улучшение диагностики ошибок", "Поддержка приоритетов операций", "Рефакторинг",
A_A>"Поддержка скобок и унарных операций", "Использование модулей".
A_A>Понятия самого языка, рассматриваемые в статье, можно перечислить в самом начале статьи (рядом с содержанием) в виде списка с ссылками на соответствующие места статьи.

В принципе можно. Но тут не ясно как это сделать технически. У формата РСДН есть свои ограничения. Оглавление формируется автоматически. Чтобы вынести главы относящиеся к фичам языка в отдельный список их придется делать обычным текстом, а не заголовками. А это сделает их незаметными в тексте.

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

Дык там и нет практически ничего. Этот раздел служит одной единственной цели — заинтересовать людей и показать им в чем та самая мощь языка. На отдельную статью этот раздел не тянет. Возможно позже будет и отдельная статья по поводу макроса PegGrammar. В ней будет полноценное описание возможностей, синтаксиса и примеры применения.

A_A>Все ИМХО

Спасибо за отклик. Постараюсь учесть замечания.

Здравствуйте, Alex_Avr, Вы писали:

A_A>5) Очень сложные и длинные предложения.

Может быть поступить иначе?...

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

Со свой стороны буду очень признателен.

Здравствуйте, VladD2, Вы писали:

VD>Может быть поступить иначе?...

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

VD>Со свой стороны буду очень признателен.

Спасибо за доверие

Присылай на alex.avr( at )gmail.com

Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:

ЧВЮ>Лямбды умеют все, что умеют локальные функции, кроме рекурсивного вызова самих себя (по понятным причинам, ведь у лямбд просто нет имени).

Это очень спорное утверждение

Причина по любому непонятна, поскольку есть Y-комбинатор (http://www.rsdn.ru/forum/decl/2135829.1.aspx

Автор: z00n
Дата: 28.09.06

).
Y-комбинатор не работает в Немерле? — вроде должен работать (http://www.rsdn.ru/forum/nemerle/3706961.1.aspx

Автор: hardcase
Дата: 16.02.10

).

Предлагаю просто выкинуть все предложение.

Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:

ЧВЮ>Первое, что для этого нужно сделать – добавить новые типы токенов – OpenBrace (открывающая скобка) и CloseBrace (закрывающая скобка).
Brace — это фигурная скобка, правильнее назвать токен Open/CloseParen или Left/RightParen. (http://www.lysator.liu.se/hackdict/split/ascii.html)

Здравствуйте, z00n, Вы писали:

Z>Это очень спорное утверждение

Z>Причина по любому непонятна, поскольку есть Y-комбинатор (http://www.rsdn.ru/forum/decl/2135829.1.aspx

Автор: z00n
Дата: 28.09.06

).

Однажды на лоб ко Льву Толстому сел комар. Толстой убил комара.
— Как же так, Лев Николаевич? – говорят ему, — Вы же сторонник непротивления злу насилием. У комара, может быть, есть семья, дети. А Вы его убили.
— Не надо жить так подробно, — отвечал Лев Толстой.

Z>Предлагаю просто выкинуть все предложение.

Предлагаю не вдаваться в подробности объяснения рассчитанного на новичка.

Здравствуйте, z00n, Вы писали:

ЧВЮ>>Первое, что для этого нужно сделать – добавить новые типы токенов – OpenBrace (открывающая скобка) и CloseBrace (закрывающая скобка).
Z>Brace — это фигурная скобка, правильнее назвать токен Open/CloseParen или Left/RightParen. (http://www.lysator.liu.se/hackdict/split/ascii.html)

Мне казалось, что фигурные скобки это curly brace или squiggle bracket. Ну, да в английском я никогда силен не был. Поправим...

Спасибо.

Здравствуйте, VladD2, Вы писали:


Z>>Предлагаю просто выкинуть все предложение.

VD>Предлагаю не вдаваться в подробности объяснения рассчитанного на новичка.

Я и предложил, не вдаваясь в подробности, убрать неверное утверждение

Здравствуйте, z00n, Вы писали:

Z>Я и предложил, не вдаваясь в подробности, убрать неверное утверждение

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

Если заняться занудным обяснением всех тонкостей, то получится скучно, ежело и не понятно.

Таких мест в статье очень много. Просто тебе бросилось одно из них.

ЗЫ

Единственное что могу сделать — добавить врезку где сказать, что все немного сложнее и, что о Y-комбинаторах я в курсе.

Здравствуйте, VladD2.

VD>>Может быть поступить иначе?...

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

Мое письмо от 8.08.2010 пришло?

С уважением,

Александр Авраменко.