M>>При этом с ПМ рекрсия по списку тривиальна
SR>Неужели считаете, что цикл нетривиален?

Он менее "читаем", чем ПМ

M>>

M>>{ok, {{Version, 200, ReasonPhrase}, Headers, Body}} =
M>>      http:request(...
      
M>>{ok, {_, _, Body}} = http:request(...


M>>{ok, {_, 200, _}, _, _} = http:request(
M>>

M>>Какой-какой автоматизированый equals мне поможет это написать?
SR>Как-то определили, что мне знаком erlang?

Ну, мы ж про паттерн-матчинг говорим? А тут вполне себе паттерн-матчинг. Вполне понятный даже незнакомому с Эрлангом

SR>Потом, предлагаю, не отвлекаться каждый раз на свои структуры.
SR>Как повелось сторонниками ФП демонстрировать преимущества сопоставления с образцом на основе структур для условного калькулятора так предлагаю и продолжать.
SR>Нет, если конечно считаете, что у вас какая-то принципиально иная структура, которая в калькулятор не укладывается.

Ну, в исходном

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

сообщении был приведен и пример кода их компилятора

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

Автор: SmbdRsdn
Дата: 22.04.08

— реализация метода equals, здесь

Автор: SmbdRsdn
Дата: 24.04.08

— функции с применением if-ов). А ПМ в итоге позволяет читать код, как книгу, без необходимости пробираться сквозь дебри if-ов и попыток понять, что же автор хотел сказать тем или иным циклом

SR>>>Странно, стороннику ФП не нравятся отдельные функции. Ну раз не нравятся объедините в одну большую.

M>>В какую ону большую? В Tom что ли?
SR>Гм, по вашему одна большая функция не разбитая на малые превращается сразу в язык программирования Tom. Интересная способ рассуждений.

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


SR>>>Пример не более тривиален чем исходный.

M>>

M>>     | {i,FLT,{'Break',s}} :: z -> return best(emit(sb,s),n,k+#s,z)
M>>     | {i,BRK,{'Break',_}} :: z -> return best(nl(sb,i),i,i,z)
M>>     | {i,FLT,{'Group',x}} :: z -> return best(sb,w,k,{i,FLT,x}::z)
M>>

M>>это, я так понимаю, предлагается переписать в виде
M>>

M>>if(term.m == FLT && term.cell.type == 'Break' && term.cell.data == s)
M>>{
M>>}
M>>else if(term.m == BRK && term.cell.type == 'Break')
M>>{
M>>}
M>>else if(term.m == FLT && term.cell.type == 'Group' && term.cell.data == x)
M>>{
M>>}
M>>

M>>?
SR>Нет. Вспомните, я и код такого вида не приводил.

Ну, для калькулятора был код с term.equals, для проверки веб-=форм был код с if'ами. Для этого конкретного примера term.equals не подойдет, потому что нам не всегда все значения нужны. Так что if-ы

M>>Любая, где требуется разбор структур (данных). Сопоставление с образцом — это унифицированый подход к разбору произвольных структур(данных)
SR>Это вы хватили, насчет произвольных структур. Вот например разработчики Tom'а заявляли, что в Tom возможно сопоставлять с образцом более сложные структуры чем в Scala, но все равно не произвольные.

Это, возможно, ограничения языков и/или JVM.

M>>Более того, реализация сильно похожа на то же самое
SR>В реализации многовато дублирования образцов. Практически каждый по два раза.

Это мои кривые руки.


M>>Но у меня, безусловно, простой пример. А есть посложнее. Типа того, что я привел в самом начале.
SR>Про посложнее это понятно. Однако считается, что преимущество сопоставления с образцом видно уже на простых иерархиях.
SR>А у вас странно звучит — да на простой иерархии особой разницы не видно, но если ее навернуть на порядок, тогда преимущество будет очевидно.

На простых просто как раз и начинается- а вот тут я могу if'ом, а вот тут — функцией...


Хотя... Опять же. ПМ предлагает одинаковый подход к решению всех приведенных здесь примеров. Который еще и очень легко читается.