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.

Hi Alberto, On Tue, Jun 28, 2016 at 10:04 AM, Alberto G. Corona wrote:

Corentin:

Transient has the same behaviour than your reactive library. Your library must produce two results if you press the first and then the second button, (and more if you press them more times).

Actually no, in Nomyx the events, when they occur, are "consumed" and deleted (replaced by their result). So in the case of: True <$ inputButton "click here for True" <|> False <$ inputButton "click here for False" Once one of the buttons is clicked, both disappear and the result is produced. But it's merely a design choice I suppose...

In the example, return "hello" and return "world" are two different events that are triggered inmediately, and each one produces an output.

The Transient EDSL for Web programming has the same behaviour than yours and use the same <|>

(submitButton "hello" `fire` OnClick) <|> (submitButton "world" `fire` onClick)

return either one or the other. But it can produce, like yours (I suppose) two or more results, as many events as you trigger.

I like a lot Transient, I would have surely used it in Nomyx if it was around some years ago :) One question is, Transient seems a lot dependant on the IO monad, would it be possible to abstract from it?

2016-06-28 0:31 GMT+02:00 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

...

:

...

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.