SR>Вы не поняли изначально. В вашем коде и моем нет сопоставления цикл — pattern matching. А есть сопоставление цикл — рекурсия.
SR>А нужна она для того, чтобы после разбора начала списка, разобрать хвост списка. Это же стандартная тема сопоставления ФП и ИП.

Ничего не понял

M>>И это называется удобным???

M>>На каждый случай писать свою, отдельную, специализированную функцию, заточенную под разбор только данного конкретного случая?
SR>Гм, у вас какое-то преувеличение насчет списков. Эта структура данных известна давным давно, все с ней более менее ясно.


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

SR>С чего вы взяли, что там отдельная специализированная функция? Там обобщенная. А класс Response всего лишь обертка, которую можно и не заводить.
SR>Я же его завел, потому что мне хотелось иметь инфиксную форму вызова matches.
SR>А так было бы,
SR>

SR>boolean matches(Object[] list, Object[] pattern) {
SR>}
SR>

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

Так никто про списки изначально и не говорил


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

Как это реализовано внутри — это очень важно. Во всех примерах на Яве приходилось задвигать передаваемые данные в прокрустово ложе if'а (case'а), потому что ни if ни case не разбирают структуру разбираемых данных.

SR>Неужели считаете, что в Scala сопоставление со списком и с вариантами это одна функция? Конечно, это может быть и так, но скорее всего их тоже две.

Да, но прогарммисту, это использующему — абсолютно все равно:

case input_data of
    [{elem1, elem2}|T] -> сделаем что-то одно
    [[L]|T] -> разбираем вложенный список
    {a, b} -> а ждесь вообще не список, оппаньки
    {[H|T], [H2|T2]} -> и здесь не список передали. но внутри список
    {a, {b, {c, d}}} -> здесь списком даже и не пахнет, но все разобрали
    {_, _, _, _, x} -> нам важен только 5-й параметр, хотя струкутра может быть такой:
    {{a, b, c}, [H|T], {[H2|T2]}, d, e} -> и все равно мы ее сможем разобрать
end

M>>ПМ позволяет использовать унифицированый подход к разбору как структуры так и значений:
SR>Сопоставление с образцом в Java позволяет ровно тоже самое.

Не позволяет. Его в Яве нет. Все, что есть — это if/case, которые структуру разобрать не позволяют.


M>>Я с удовольствием посмотрю на общую функцию match, которая разберется со всеми этими примерами одним махом.

SR>[поскипаны примеры псевдокода]

что за list.match()? кто его написал? откуда он взялся? он будет работать для произвольных данных?


M>>Сомневаюсь. Выше приведено четыре примера, на каждый из которых с нашей стороны был приведен простейший декларативный код с ПМом, а с вашей — четыре разные функции, которые еще и накладывают ограничения на реализацию (например, необходимость реализации метода equals в первом примере)

SR>С моей стороны функции, не приводились, а приводился лишь образец для сопоставления.
SR>И случаев относящихся к сопоставление с образцом не четыре, а два. Сопоставление со списком, и сопоставление с вариантами.

И для каждого случая пришлось писать отдельную функцию, разбирающую отдельную структуру только в данном конкретном случае для того, чтобы вернуть true/false, чтобы это можно было проверить if/case'ом

M>>и if и case могут проверять только значения. ПМ позвляет проверять и структуру и значения сразу, без какойлибо дополнительной работы со сторноы программиста. В этом — главное и основное отличие
SR>Так же и при сопоставлении с образцом в Java.

Еще раз — Java такого не позволяет:

ПМ:

match({1, 2, 3}) ->
    ok;

match({"a", "b", "c"}) ->
    ok;

match([H|T]) ->
    ok.

Как общим кодом на Яве узнать, что:
— в первом случае у нас объект с тремя целочисленными полями
— во втором — с тремя текстовыми полями
— в третьем — вообще списко/массив
?

Более того, если нас не интересует тимп полей, а только их структура? Сколько перегруженых операторов equals придется писать для каждого отдельного случая?