История изменений

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

Так у свизарда всё равно была структура и использовалась она не лучшим образом — где лишний код (в synchronize-from-etc-passwd-to-hash-db) и лишний (в данном случае) apply я показал.

Вообще, в обобщённом коде который не знает как будут общаться поставщики и приниматели может иметь смысл делать либо (thing), либо (&rest things). В первом случае между функциями будет летать просто один object — кому нужен атомарный объект сделает на него funcall и получит атомарный объект, кому нужен lambda-list — сделает funcall на список и поднимет себе нужный lambda-list явно одной строчкой с destructuring-bind, values-list — multiple-value-call и multiple-value-bind. Во втором случае ценой apply везде будут неявно подниматься lambda-list и летать списки (как бы в хаскеле тоже ничего не мешает летать кортежам и спискам и матчить их паттерн-матчингом, разве что :keys не получится сделать).

аналог исходного кода в хаскеле будет в 10 раз длиннее, в 10 раз менее понятен

Вот только он вышел короче (и про passwd в первом приближении тоже короче пишется — тупо по lines и split из ленивого IO). Что касается непонятности кем-либо кто не знает языка, я извиняюсь, — мне это не интересно :)

И, конечно, все эти f, g и прочие однобуковки надо заменить на нормальные названия

Нормальных названий нет, потому что никаких user тут нет. Просто так получилось, что этот syn (и никакой не syn вовсе) часть более общего (аппликативного) паттерна. То есть эта дуля на пять строк принимает какие-то функции и как-то их вызывает, вся конструкция не имеет отношения к задаче, суть просто f $ \x -> g x (h x) — не писать же, например, compose для каждого «домена»? Это всё понятно. И f $ \x -> g x (h x) это f $ g <*> h в случае (->) r. Непонятно? Ну и ладно.

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

Так у свизарда всё равно была структура и использовалась она не лучшим образом — где лишний код (в synchronize-from-etc-passwd-to-hash-db) и лишний (в данном случае) apply я показал.

Вообще, в обобщённом коде который не знает как будут общаться поставщики и приниматели может иметь смысл делать либо (thing), либо (&rest things). В первом случае между функциями будет летать просто один object — кому нужен атомарный объект сделает на него funcall и получит атомарный объект, кому нужен lambda-list — сделает funcall на список и поднимет себе нужный lambda-list явно одной строчкой с destructuring-bind, values-list — multiple-value-call и multiple-value-bind. Во втором случае ценой apply везде будут неявно подниматься lambda-list и летать списки (как бы в хаскеле тоже ничего не мешает летать кортежам и спискам и матчить их паттерн-матчингом, разве что :keys не получится сделать).

аналог исходного кода в хаскеле будет в 10 раз длиннее, в 10 раз менее понятен

Вот только он вышел короче (и про passwd в первом приближении тоже короче пишется — тупо по lines и split из ленивого IO). Что касается непонятности кем-либо кто не знает языка, я извиняюсь, — мне это не интересно :)

И, конечно, все эти f, g и прочие однобуковки надо заменить на нормальные названия

Нормальных названий нет, потому что никаких user тут нет. Просто так получилось, что этот syn (и никакой не syn вовсе) часть более общего (аппликативного) паттерна. То есть эта дуля на пять строк принимает какие-то функции и как-то их вызывает, вся конструкция не имеет отношения к задаче, суть просто f $ \x -> g x (h x) — не писать же, например compose для каждого «домена»? Это всё понятно. И f $ \x -> g x (h x) это f $ g <*> h в случае (->) r. Непонятно? Ну и ладно.