declarative

[thedeemon]

Периодически встречаю словосочетание "декларативное программирование", которое противопоставляют императивному, сопровождая формулой "описывается, что должно быть получено, а не как оно должно быть получено". Известный пример декларативного языка - SQL. Еще к декларативщине частенько относят хаскель и другие ФЯ, но вот с ними проблема: сколько кода я на них видел, (практически) везде было явное описание процесса вычисления, т.е. код был все же императивным по сути (создать список такой-то, свернуть его так-то, построить дерево такое-то и т.д. - это все про "как"). Вопрос к залу: покажите максимально декларативное решение (на любом языке, в том числе еще не существующем и чисто гипотетическом) следующей задачи.

Есть последовательность байтов (фиксированный массив/список или потенциально бесконечный поток - на ваш выбор), нужно их сжать RLE методом по мотивам формата PCX: в выходном потоке байт Х <= 192 обозначает сам себя, а байт Х > 192 означает Х-192 повторений следующего за ним байта. Т.е. последовательность
1, 1, 2, 3, 2, 2, 2, 200, 0, 200, 200, 200, 200
должна превращаться в
194, 1, 2, 3, 195, 2, 193, 200, 0, 196, 200

Comments

[thedeemon.livejournal.com]

По задумке изначально никакой четкой спецификации не давалось, есть просто "задача". Как это и бывает обычно. Собственно, построение исполняемой спецификации, видимо, и будет хорошим решением.

Ваш вариант интересный. Я правильно понимаю, что он работает справа-налево и применим лишь к конечным спискам? В случае потока данных его надо сильно менять?

[sassa-nf.livejournal.com]

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


"справа-налево"

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