Как и обещал, размышления1. Во-первых, сопоставление с образцом позволяет быстро и достаточно безболезненно описывать требуемое. Например, возьмем правила:{field} {field, Func} {field, {'=', field2}} Честно говоря, я слабо себе представляю, как это обработать if'ами. Думаю, все это пришлось бы оборачивать в какой-нибудь класс Rule и наследовать от него классы RuleField, RuleFunc, RuleOperator и так далее. Используя сопоставление с образцом, такие правила разребаются очень просто:%%{field} validate_rule({FieldName}) -> ok. %%{field, Func} validate_rule({FieldName, Func}) when is_function(Func) -> ok. %%{field, {'=', field2}} validate_rule({FieldName, {Operator, FieldName2}}) -> ok. Правда, такая легкость приводит (меня, во всяком случае) к пункту 2:2. Индусокод. Эта легкость в обработке сложных конструкций моет привести к тому, что начинаешь просто писать функции, их обрабатывающие, вместо того, чтобы остановиться и подумать - а оно мне надо?В моем случае это вылилось в то, что я вроде как бы знал, что я хочу в функцию передать. Хорошо, это я обработал. А возвращать что будем? А что с результатами делать будем?В итоге, в самом начале функция возвращала дикую конструкцию такого вида: [[Field, [Error1, Error2]], [Field2, [Error3, Error4]]] то есть глубокий список списков. Это сейчас она возвращает более-менее proplist. С третьей попытки :)Этот же подход в стиле "вау, посмотри, что я могу обработать, а что вернем - неважно" привел к тому, что перед возвращением значения происходит следующая обработка: lists:filter( fun(Elem) -> case Elem of {} -> false; {_, []} -> false; _ -> true end end, lists:flatten(validate1(A, ValidationRules, []))) Дадада. Вычищаем список от нежелательных элементов. Вам страшно? Мне - да. Мне еще и грустно :(На этом мысль закончилась...