Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо.
У Fran насколько я понимаю утечки были вообще очень суровые (там вроде Behaviour моделился чуть-ли не прямо как Time -> a). Если описывать Behavior тупым continuation и не писать рекурсивных выражений типа "e = 1 + integral e" (хаскелл все-таки уравнения не решает), то проблем особых нет. Возможно их нет только в кемле, в котором вообще таких выражений записать нельзя, но раз получилось обойтись без них, то может и в хаскеле проканает.
Arrow-based конечно ограничивает утечки, но оно даже Conal-у не нравится (хотя его вроде и не он придумал). Есть подозрение, что именно из-за стремных стрелок и усиленной паники по-поводу space/time leak-ов FRP так и не пошел в массы. Но, по крайней мере в кемле, оно работает и за последние три года в нем ничего не текло. Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Не очень понял про способ избежать ликов в Data.Reactive? Можно поподробнее? Сам Data.Reactive как я понял нифига несинхронный (справшивал тут у Conal-а, говорит Not quite. mappend passes along the intermediate and final values, and the cleverness to ignore them is in the display end. т.е. надо ручками отлавливать промежуточные значения, а если по ним происходит переключение где-то внутри, то и не отловишь). А раз несинхронный, то и недетерминированный, что меня вообще никак не радует.
> Не очень понял про способ избежать ликов в Data.Reactive?
Если б я сам понял, я был бы очень счастлив :-)
Про примерно этот метод было еще в старом блоге Luke Palmer (да и вобще по идее проще всего разобраться в коде fregl, он относительно простой). Вроде бы оно все на stm базируется. Если вы что-нибудь поймете, объясните пожалуйста :-)
А Data.Reactive по-моему я вобще понять в ближайшие пару лет не смогу :-)
> Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
Что-то у него ссылка на fregl куда-то на luigi.org, а тот недоступен.
А название поста или какие-нить ключевые слова, как поискать "про примерно этот метод".
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
Вот и у меня такое подозрение. Я читал про time/space leak-и и так до конца и не понял про что это они все пишут (вернее понял, но не понял где и зачем надо так писать, чтобы эти утечки появились). Читаю блог Conal-а и в последнее время вообще не понимаю те проблемы, которые он пытается решить (вернее понимаю, что они к его Data.Reactive относятся и еще к каким-то абстрактным задачам, но с моими задачами оно ну никак не соприкасается).
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
Дык я не ученый, я программер. У меня нет работ, у меня проекты. Вот сейчас пытаюсь выцепить, то что более-менее оформилось и сделать из этого библиотеку на хаскеле (изначально у меня все на кемле). Ее думаю куда-нить выложить и поблогать на тему FRP (идеи/тьюториал + real world (как писать модульно, как оптимизить и т.д.). Но это все неизвестно когда произойдет.
> Т.е. утечки -- это вообще не проблема.
> Утечек они сами по себе не содержат.
Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо.
У Fran насколько я понимаю утечки были вообще очень суровые (там вроде Behaviour моделился чуть-ли не прямо как Time -> a). Если описывать Behavior тупым continuation и не писать рекурсивных выражений типа "e = 1 + integral e" (хаскелл все-таки уравнения не решает), то проблем особых нет. Возможно их нет только в кемле, в котором вообще таких выражений записать нельзя, но раз получилось обойтись без них, то может и в хаскеле проканает.
Arrow-based конечно ограничивает утечки, но оно даже Conal-у не нравится (хотя его вроде и не он придумал). Есть подозрение, что именно из-за стремных стрелок и усиленной паники по-поводу space/time leak-ов FRP так и не пошел в массы. Но, по крайней мере в кемле, оно работает и за последние три года в нем ничего не текло. Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Не очень понял про способ избежать ликов в Data.Reactive? Можно поподробнее? Сам Data.Reactive как я понял нифига несинхронный (справшивал тут у Conal-а, говорит Not quite. mappend passes along the intermediate and final values, and the cleverness to ignore them is in the display end. т.е. надо ручками отлавливать промежуточные значения, а если по ним происходит переключение где-то внутри, то и не отловишь). А раз несинхронный, то и недетерминированный, что меня вообще никак не радует.
Reply
Если б я сам понял, я был бы очень счастлив :-)
Про примерно этот метод было еще в старом блоге Luke Palmer (да и вобще по идее проще всего разобраться в коде fregl, он относительно простой). Вроде бы оно все на stm базируется. Если вы что-нибудь поймете, объясните пожалуйста :-)
А Data.Reactive по-моему я вобще понять в ближайшие пару лет не смогу :-)
> Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
// pierre
Reply
А название поста или какие-нить ключевые слова, как поискать "про примерно этот метод".
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
Вот и у меня такое подозрение. Я читал про time/space leak-и и так до конца и не понял про что это они все пишут (вернее понял, но не понял где и зачем надо так писать, чтобы эти утечки появились). Читаю блог Conal-а и в последнее время вообще не понимаю те проблемы, которые он пытается решить (вернее понимаю, что они к его Data.Reactive относятся и еще к каким-то абстрактным задачам, но с моими задачами оно ну никак не соприкасается).
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
Дык я не ученый, я программер. У меня нет работ, у меня проекты. Вот сейчас пытаюсь выцепить, то что более-менее оформилось и сделать из этого библиотеку на хаскеле (изначально у меня все на кемле). Ее думаю куда-нить выложить и поблогать на тему FRP (идеи/тьюториал + real world (как писать модульно, как оптимизить и т.д.). Но это все неизвестно когда произойдет.
Reply
Reply
Leave a comment