Хаскельно-кложурное
May. 19th, 2012 10:59 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassА вот, тащемта, можно ли и каким образом на хаскеле можно сделать обобщенную функцию такого вида:
На вход подается список функций разных типов, но общей структуры вроде такой:
f :: state -> input -> (new_state,output) (такая функция описывает блок обработки сигналов, с внутренним состоянием, типа фильтра).
На выходе наша обобщенная функция должна выдать нечто такое:
f_all :: state_all -> input_all -> (new_state_all,output_all), где state_all,input_all,output_all - объединение (кортеж) соответственно из всех состояний, входов и выходов переданных на вход функций. То бишь наша функция, из N блоков обработки сигналов делает 1 блок, входы которого - это входы всех составляющих блоков, выходы - выходы составляющих блоков и состояние аналогично.
На кложури с ее макросами и отсутствием строгой системы типов такое делается практически в лоб, за исключением необходимости описывать функции блоков в виде, доступном для преобразования (то ли через рефлекшн, то ли макрос, который опишет функцию с метаданными, то ли есть что-то встроенное). Единственный не совсем ясный вопрос - тип возвращаемого значения из кложурной функции не особо то и узнаешь.
Далее там еще есть необходимость сгенерировать описание соединений (т.е. функция, которая из state_all и части свободных входов генерирует input_all), но над этим пока думать влом)
PS: в общем, забавность ситуации в том, что строгая типизация помогла бы находить ошибки в блоках и соединениях, но с ней возникает необходимость использовать гетерогенные списки, SYB и прочую олеговщину. Причем я в это утыкаюсь регулярно - то с оперденями, то вот сейчас с обработкой сигналов.
На вход подается список функций разных типов, но общей структуры вроде такой:
f :: state -> input -> (new_state,output) (такая функция описывает блок обработки сигналов, с внутренним состоянием, типа фильтра).
На выходе наша обобщенная функция должна выдать нечто такое:
f_all :: state_all -> input_all -> (new_state_all,output_all), где state_all,input_all,output_all - объединение (кортеж) соответственно из всех состояний, входов и выходов переданных на вход функций. То бишь наша функция, из N блоков обработки сигналов делает 1 блок, входы которого - это входы всех составляющих блоков, выходы - выходы составляющих блоков и состояние аналогично.
На кложури с ее макросами и отсутствием строгой системы типов такое делается практически в лоб, за исключением необходимости описывать функции блоков в виде, доступном для преобразования (то ли через рефлекшн, то ли макрос, который опишет функцию с метаданными, то ли есть что-то встроенное). Единственный не совсем ясный вопрос - тип возвращаемого значения из кложурной функции не особо то и узнаешь.
Далее там еще есть необходимость сгенерировать описание соединений (т.е. функция, которая из state_all и части свободных входов генерирует input_all), но над этим пока думать влом)
PS: в общем, забавность ситуации в том, что строгая типизация помогла бы находить ошибки в блоках и соединениях, но с ней возникает необходимость использовать гетерогенные списки, SYB и прочую олеговщину. Причем я в это утыкаюсь регулярно - то с оперденями, то вот сейчас с обработкой сигналов.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-19 01:50 pm (UTC)С хаскелем непонятно. Странные многоуровневые туплы на выходе гетерогенных списков напрягают.
no subject
Date: 2012-05-19 01:55 pm (UTC)no subject
Date: 2012-05-19 01:57 pm (UTC)no subject
Date: 2012-05-19 02:03 pm (UTC)А то я по пути наименьшего сопротивления пока использую Clojure, но очень уж интересно эти задачи в строгой типизации и ленивости оформить. Правда, скажем, с ком-портом на хаскеле получилась ересь - либо tight-coupling (т.е. логика и обмен с внешним миром никак не разделены) либо адовы iteratees и аттопарсеки с багами.
no subject
Date: 2012-05-19 02:40 pm (UTC)no subject
Date: 2012-05-19 02:42 pm (UTC)no subject
Date: 2012-05-20 01:35 am (UTC)