
2016-06-29 10:31 GMT+02:00 Corentin Dupont
I understand, my comment was just on the syntax. Actually I have the same problem with "guard":
test x = do guard x XXXXXXXXX YYYYYYYYY ....
Unless I read all the monad body, there is no visual cue that XXX and YYY might not be run. The control flow is not syntactically visible. That's why I prefer using guards like that:
test x = do guard x >> do XXXXXXXXX YYYYYYYYY ....
Here the indentation shows that there is a control flow decision. Is it possible to do the same thing with Transient? Something like:
main = keep $ do async (return "hello") <|> async (return "world") >>= \r -> do liftIO $ print r
Yes, it is possible, just like in any other monad. but the alternative expression must be in parenthesis if you want both results to be printed. I do not remember which operator has more precedence <|> or >>=. I guess >>=
main = keep $ do (async (return "hello") <|> async (return "world")) >>= \r -> do liftIO $ print r
On Tue, Jun 28, 2016 at 7:25 AM, Geraldus
wrote: This is because the whole computation is kept (via `keep`). If you just run computation with `runTransient` you will see only “world” in output and then program ends, however since the computation is kept when second action finishes it prints “hello”.
`r <- async … <|> async …` Here `r` is a continuation, everything below it will be re-computed when any of alternatives will return a result. For example, you can add another choice: `r <- async … <|> async … <|> waitEvents someEventAction` In this case every time your `someEventAction` returns a value `r` takes it and the rest of code re-executed (or in other words when you have a new continuation the computation re-evaluated).
Hope this makes sense.
вт, 28 июн. 2016 г. в 3:31, Corentin Dupont
: Wow, it is very impressive. I need to give it more time. I have one question regarding this example:
main = keep $ do th <- liftIO myThreadId -- thread 89 r <- async (do threadDelay 1000000; return "hello") -- thread 90 <|> async (return "world") -- thread 91 th' <- liftIO myThreadId -- thread 90 and 91 liftIO $ print (th, th', r) -- thread 90 and 91
Output:
(ThreadId 89,ThreadId 91,"world") (ThreadId 89,ThreadId 90,"hello")
For me it's counter-intuitive that there are two outputs. What is the reason behind? It seems that the use of the <|> affects the rest of the program. It looks strange to me because the two lines situated after the <|> does not look "syntactically" involved, if you see what I mean. Instead I was expecting only one output, with the first thread to finish "wins". In fact I implemented it like that: http://www.corentindupont.info/blog/posts/Programming/2014-09-23-Nomyx-Langu...
Cheers Corentin
On Mon, Jun 27, 2016 at 8:22 PM, Geraldus
wrote: Sorry, here is some links: Wiki paga on GitHub https://github.com/agocorona/transient/wiki/Transient-tutorial Programming at specification level https://github.com/agocorona/transient/wiki/Programming-at-the-specification...
пн, 27 июн. 2016 г. в 23:19, Geraldus
: Hi! Have you looked at Transient by Alberto Gomez Corona?
пн, 27 июн. 2016 г. в 18:27, Corentin Dupont < corentin.dupont@gmail.com>:
Hi Joachim, I agree... I looked hard at them :) https://wiki.haskell.org/Functional_Reactive_Programming
I need a library with a DSL able to create forms on the fly, in a "demand driven" way. I.e. if at some point in time the user program needs a boolean from the user, a radio button will be created on the screen of that user. The objective is to retrieve the boolean, creating the form is just a way to do that. Complex forms can be created, capable of generating full ADTs. The styling of the form is not important. Other requirements: - it should be possible to run the event DSL in a monad different from IO. - the event DSL need to be instance of Alternative: events can be put in concurrence, the first to fire wins.
On Mon, Jun 27, 2016 at 10:25 AM, Joachim Breitner < mail@joachim-breitner.de> wrote:
> Hi, > > Am Montag, den 27.06.2016, 09:38 +0200 schrieb Corentin Dupont: > > I need it for the game Nomyx, but couldn't find the features I > wanted > > from the existing libraries. > > any chance to extend existing libraries to support what you need? > Library proliferation does not really help the ecosystem. > > Greetings, > Joachim > -- > > Joachim “nomeata” Breitner > mail@joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata@debian.org > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. >
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Alberto.