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



On Tue, Jun 28, 2016 at 7:25 AM, Geraldus <heraldhoi@gmail.com> 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 <corentin.dupont@gmail.com>:
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-Language.html#event-alternative-interface

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <heraldhoi@gmail.com> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <heraldhoi@gmail.com>:
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.