почему же, его вполне себе можно сравнивать с Haskell — уже хотя бы потому, что оба позиционируются как ФП-яыки для real world programming. я бы даже сказал что такое сравнение будет весьма и весьма полезным
хотелось бы код для эффективной реализации сортировки Хоара, сравнимой по произовительности с императивным эквивалентом
ну и сравнение F# с OCaml и SML (SML.Net) также весьма не помешает
насчёт энергичности и производительности, к слову, чушь; было бы очень интересно посмотреть на примеры выигрыша F# над Haskell в производительности по причине энергичности первого и ленивости второго
а, ну ещё, просто как комментарий — раз уж пример корекурсии всё равно дан, да и fold фигурирует,- почему бы не упомянуть и unfold заодно?
ну или убрать бесконечные списки вообще :) а то как-то получается, что бесконечные структуры данных упоминаются в отрыве и от unfold'ов, и от специфики ленивого программирования
означает, ещё как. то есть Вы мыслите правильно, но неправильно понимаете что такое аппликация в смысле лямбда-исчисления :) варианта «если не повезёт» быть не может — тайпчекер не пропустит некорректное выражение
а запись такая, конечно, логичней. именно поэтому она такая, вообще говоря
интересней было бы сравнить GUI на FRP/AFRP (тот же FranTk) с чисто событийным Tcl/Tk. особенно учитывая тот факт, что возможности построения eDSL для Haskell весьма неплохи (от комбинаторов до квазиквотации): С++/Tk-подобных извращений писать не придётся
а по поводу корректных программ стоит добавить, что подстановочная модель позволяет использовать формальные методы матлогики для статической верификации приложения: в императивных языках о таком можно только мечтать
GUI на Haskell писать как раз достаточно удобно — равно как и, скажем, на Prolog (см. XPCE для SWI-Prolog); во всяком случае куда удобней чем на C++ (хотя и не так удобно как на Tcl/Tk)
достаточно понять, что UI — это реактивная событийная модель, которая замечательно выражается в терминах именно ФП (см. Reactive Элиотта); ну а графическая часть по определению должна описываться декларативно (см. тот же WPF в сравнении с WinForms)
другое дело, что нет доведённых до ума законченных GUI-библиотек для Haskell — ну так это потому, что никто этим специально не занимался
ну и сравнение F# с OCaml и SML (SML.Net) также весьма не помешает
насчёт энергичности и производительности, к слову, чушь; было бы очень интересно посмотреть на примеры выигрыша F# над Haskell в производительности по причине энергичности первого и ленивости второго
ну или убрать бесконечные списки вообще :) а то как-то получается, что бесконечные структуры данных упоминаются в отрыве и от unfold'ов, и от специфики ленивого программирования
а запись такая, конечно, логичней. именно поэтому она такая, вообще говоря
а по поводу корректных программ стоит добавить, что подстановочная модель позволяет использовать формальные методы матлогики для статической верификации приложения: в императивных языках о таком можно только мечтать
достаточно понять, что UI — это реактивная событийная модель, которая замечательно выражается в терминах именно ФП (см. Reactive Элиотта); ну а графическая часть по определению должна описываться декларативно (см. тот же WPF в сравнении с WinForms)
другое дело, что нет доведённых до ума законченных GUI-библиотек для Haskell — ну так это потому, что никто этим специально не занимался