если собирать hie, то можно, там прописаны нужные версии гхцмода и кабал-хелпера

у меня пдфка есть, могу скинуть, если хотите

Давай

streaming прикольный

А у него есть аналог wait, или как скомпозить выход одного стрима во вход следующего?

выход в смысле return value?

не, то, что первый съелдил

там у тебя прямой доступ к структуре стрима - можно что хочешь делать

эм, а как такого может не быть?

а >>> нельзя ?

stream2 . stream1

конечно можно, но это же везде можно?

хм, а как в stream2 взять что пришло - как раз паттернматчингом по первому элементу?

можно матчингом. можно next можно всякими map/fold

имею ввиду, что в pipes, например, можно await и один стрим в другой передать как >->

ок, надо попробовать

у стрима нет фиксированного инпута, поэтому они не композятся, как пайпы

стрим эквивалентен (изоморфен) Producer в терминах пайпов

Хугл прилёг ? https://www.haskell.org/hoogle/

эм.. отличие пайпов, в том, что у них с upstream общаться можно

https://www.stackage.org/lts-10.0/hoogle?q=map (правда новая версия хугла не работает)

Блин. Туториалы устарели. http://haskell-distributed.github.io/wiki/networktransport.html количество переменных у createTransport поменялось https://hackage.haskell.org/package/network-transport-tcp-0.6.0/docs/Network-Transport-TCP.html https://hackage.haskell.org/package/network-transport-tcp-0.3.1/docs/Network-Transport-TCP.html

и как нуб хз где брать новый "лишний" параметр ?

Вернее как я понял надо скормить функцию, которая бы внешний адрес и порт давала, принимая истиный адрес O_o

Только... не знаю где взять её. Есть идеи?)

(конечно можно юзать старый lts или старый пакет, пока не научусь, но мне кажется это костыльно)

в простейшем случае они будут совпадать с предыдущими

т. е. createTransport host port (\_ -> (host, port)) ...

если я правильно понимаю

если сервис за каким-нибудь NAT, то ему нужен один адрес, чтобы слушать, а другой, чтобы пакеты снаружи приходили

или так createTransport host port (\p -> (host, p)) ...

Эй, функциональщики, вот оно как

ну там же все нарисовано

можно даже ответ не писать

Свинки ФэПы

А если честно, то React+Redux можно готовить так, что будет даже пристойно. Настолько, насколько вообще можно сделать в JS

js непристоен?

конечно

> [] + {} "[object Object]"

Он мало того, что динамически типизирован, так ещё и слАбо. И вообще JS не сподвигает делать хорошо. И сообщество не сподвигает. И культура делать нормально отсутствует.

а вот ни у кого небыло мыслей реализации подобных языков на хаскеле?

ruby, js, io, etc

:info "реализации подобных языков"

Дело не в реализации языка же. Спецификация плохая у JS, а не рантаймы

да ну это понятно

я вообще

не лисп запилить, а жс, например

Зачем?

Зачем делать заведомо плохой язык?

да я то откуда знаю)) я не знаю откуда берутся все эти лиспы пачками

есть же реализация перла на хаскеле

> [] + {} "[object Object]"

всё нормально

да я то откуда знаю)) я не знаю откуда берутся все эти лиспы пачками

Написание лиспа, это отличное упражнение по написанию интерпретаторов, избавленное от необходимости написания ещё и сложного парсера

это наверно как изучил язык - напиши для него стандартную либу, типа микрофреймворка на рубях)

Лиспы пишут в освновном в учебных целях. По данной теме и литературы достаточно

нуу, лисп с макросами написать не сильно легче, чем жс реализовать, наверно

легче

лисп с макросами и статической типизацией не легче, траст ми

намного

ну в общем ты подставь в свои ответы любой другой язык и это будет ответ на твой вопрос "зачем?" )

С типизацией - не проще

но аккуратные удобные макры сделать тоже сложно. их даже понять сложно

Пишут обычно Scheme с дин.типизацией, а не CL

ERROR: S client not available

Scheme тоже не так прост как кажется

r7rs хитёр)

+1, да.

И схему пишут не для решения на ней конкретных задач, а для того, чтобы написать

я на этом сломался

но я правда хотел всякую метациркулярность или как это. и статические типы.

в смысле, полную спецификацию яваскрипта сложнее чем игрушечный лисп? Или сложнее чем коммон лисп?

Коммон лисп таки проще, чем JS, ящитаю. Потому как "не на лиспе" реализуется только ядро языка и рантайм. Остально пишется на этом самом лиспе

ммммммммм

ну не знаю

в общем, я не думаю, что дело в сложности языка

Срач о языках.

собака

В любом случае тот. кто сможет написать JS на хаскеле не будет этого делать - у него уже есть хаскель :)

Встраиваемую микро-схемку же написать за вечерок - приятно!

В любом случае тот. кто сможет написать JS на хаскеле не будет этого делать - у него уже есть хаскель :)

Браузер на хаскеле?

да причём тут

Браузер тоже никто писать не будет

вы типа все тут такие прагматичные хаскелисты?

только для бабла и только то, что реально надо?

Хаскель - для прагматиков!

Зачем ещё, кроме как за деньги, писать JS на Haskell?

Отвратно же!

Лучше очередную схему, или dhall какой-нить

ну мб ты курнул чего-то там, прочитал tapl и достиг какого-то там просвеления

и хз что там после тобою движет, руки чешутся языки писать)

Руки чешутся писать плохие языки?

схема тоже отвратительна, да и dhall

да, хорошие писать точно ни у кого не чешется

Руки чешутся писать плохие языки?

писать плохие языки = тренироваться до написания чего-то стоящего