Help to choose a library name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Help to choose a library name

Corentin Dupont
Hi community,
I'm writing a reactive programming library (yet another).
I need it for the game Nomyx, but couldn't find the features I wanted from the existing libraries.
Now the library is called Nomyx-Events. But I'd like to find a cool name that is not related to Nomyx...
Some propositions:
- Nomev
- Noa
Some French names:
- Imprevu (French for unforseen, like in "unforseen event").
- Rendez-vous
- Dejavu

I like a lot Imprevu. How does it sound to English native speakers?

Thanks

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
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.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Geraldus
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 <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Alberto G. Corona
In reply to this post by Corentin Dupont
Rendez-vous sounds great

2016-06-27 9:38 GMT+02:00 Corentin Dupont <[hidden email]>:
Hi community,
I'm writing a reactive programming library (yet another).
I need it for the game Nomyx, but couldn't find the features I wanted from the existing libraries.
Now the library is called Nomyx-Events. But I'd like to find a cool name that is not related to Nomyx...
Some propositions:
- Nomev
- Noa
Some French names:
- Imprevu (French for unforseen, like in "unforseen event").
- Rendez-vous
- Dejavu

I like a lot Imprevu. How does it sound to English native speakers?

Thanks

_______________________________________________
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Alberto G. Corona
In reply to this post by Corentin Dupont
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).

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.

2016-06-28 0:31 GMT+02:00 Corentin Dupont <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Corentin Dupont
Hi Alberto,


On Tue, Jun 28, 2016 at 10:04 AM, Alberto G. Corona <[hidden email]> 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 <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Corentin Dupont
In reply to this post by Geraldus
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 <[hidden email]> 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 <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.



_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Alberto G. Corona
In reply to this post by Corentin Dupont
Hi Corentin,

2016-06-29 10:21 GMT+02:00 Corentin Dupont <[hidden email]>:
Hi Alberto,


On Tue, Jun 28, 2016 at 10:04 AM, Alberto G. Corona <[hidden email]> 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?


That is because Transient is though as general purpose language, not an EDSL, so it has liftIO. But you can restrict it by creating your own EDSL over it:

newtype EDSL a= EDSL{runEDSL :: TransIO a} deriving(Monad,Applicative...

and export your own primitives that limit the possible IO operations.
 

2016-06-28 0:31 GMT+02:00 Corentin Dupont <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.




--
Alberto.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Help to choose a library name

Alberto G. Corona
In reply to this post by Corentin Dupont


2016-06-29 10:31 GMT+02:00 Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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".

Cheers
Corentin


On Mon, Jun 27, 2016 at 8:22 PM, Geraldus <[hidden email]> wrote:

пн, 27 июн. 2016 г. в 23:19, Geraldus <[hidden email]>:
Hi!  Have you looked at Transient by Alberto Gomez Corona?

пн, 27 июн. 2016 г. в 18:27, Corentin Dupont <[hidden email]>:
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.

_______________________________________________
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.