Still going? Documentation

Is this project still under active development? The documentation could deal with a lot of love for new people.

Hi Julian: Yes it is in active development of course. I'm going to fuse MFlow with transient and hplayground. See the roadmap:

2015-06-06 4:35 GMT+02:00 JulianLeviston notifications@github.com:

Is this project still under active development? The documentation could deal with a lot of love for new people.

— Reply to this email directly or view it on GitHub https://github.com/agocorona/MFlow/issues/62.

Alberto.

Hi Julian:

Yes it is in active development of course. I'm going to fuse MFlow with transient and hplayground. See the roadmap:

https://github.com/agocorona/MFlow/wiki/Roadmap

If you can contribute in any way, you are welcome

Been looking for projects in Haskell that provide similar solutions to Clojurescript projects like Reagent. None of them feel as simple. Feels like Haskell doesn't quite have the same set of tools for client-side dev that clojurescript has. Hplayground might provide the answer to that question, but it's quite tricky to fully understand what it is. The documentation seems quite opaque / difficult to understand.

What do you think/know about the Eve project, and Functional Relational Programming? (note: NOT functional reactive programming). Seems quite interesting so far. Would be quite interested in building a platform that allows "programming" as modification of code from within code itself, but unsure: does Haskell allow this form of dynamic programming?

There's often an extreme amount of pain involved in programming. It feels a bet like a "proper" programming platform would entail simply relating various "flows" of data together in a declarative "language". One gets rather bored of repeating oneself over and over with each new framework or programming paradigm or language. Re-expressing the same intent over and over is so cumbersome. Why is code not simply data types related to each other through functions? The names that Haskell seems to come up with for things seems to be so much dross, and anything but simple.

Anyway, I'm incredibly interested. I'd like to cut out repeating the same thing over and over and over.

Hi Julian .

There are a lot of interfaces of haskell with react. That is what Reagent seems to do. if that is what you are looking for, it is a matter of searching "haskell react". I can not recommend any one to you. I don´t know how difficult they are. Many haskellers tend to complicate things innecesarily. That´s true.

hplayground is different and it is more simple to use and program with it while having all "reactive" effects. I defy to anyone to create a simpler client side app for the factorial program:

import Haste.HPlay.View

main = runBody $ do wprint $ "enter the number" num <- inputInteger Nothing fire OnChange wprint $ fact num

fact 0= 1 fact n= n * fact (n-1)

http://tryplayg.herokuapp.com/try/fact.hs/edit

The documentation is not good (I expect someone to help me on that), but there are a lot of examples to play with it in the above link. I think that it is pretty intuitive, like MFlow. Ant there is a tutorial for an example application that is very complete:

https://www.airpair.com/haskell/posts/haskell-tutorial-introduction-to-web-apps

How it works is tricky and simple at the same time.When an event arrives at a certain point, it executes the sentence affected by the event and the remaining of the sentences. Just like MFlow when receives a new request. 2015-06-06 12:52 GMT+02:00 JulianLeviston notifications@github.com:

Been looking for projects in Haskell that provide similar solutions to Clojurescript projects like Reagent. None of them feel as simple. Feels like Haskell doesn't quite have the same set of tools for client-side dev that clojurescript has. Hplayground might provide the answer to that question, but it's quite tricky to fully understand what it is. The documentation seems quite opaque / difficult to understand.

— Reply to this email directly or view it on GitHub https://github.com/agocorona/MFlow/issues/62#issuecomment-109564353.

Alberto.

Concerning to functional relational, I have never read about it. But I have a completely different take of the same problem.

I think that reactive in general is an error. A reactive expression is a giant and single event handler. for all the possible events. Because it is a giant event handler, it has to detect what change and what not after his execution Otherwise some undesired effects would be re executed. The problem essentially is the same for which OOP was for: to handle asynchronous messages and state.

OOP does manually (by the programmer ) that selection of actions to perform when a mesage is received. Reactive try to automatize the selection of actions to do for each event. That can be done with a post processing of the response (for example in react.js) or by means of a pre-processing, by means of an analysis of the ,message/s and/or relations between the things that change (probably that is what the relational reactive do)

My approach (implemented in MFlow, transient and hplayground) is different, and summarized here:

https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#the-problem--parallelization--concurrency-and-inversion-of-control

2015-06-06 13:25 GMT+02:00 JulianLeviston notifications@github.com:

What do you think/know about the Eve project, and Functional Relational Programming? (note: NOT functional reactive programming). Seems quite interesting so far. Would be quite interested in building a platform that allows "programming" as modification of code from within code itself, but unsure: does Haskell allow this form of dynamic programming?

There's often an extreme amount of pain involved in programming. It feels a bet like a "proper" programming platform would entail simply relating various "flows" of data together in a declarative "language". One gets rather bored of repeating oneself over and over with each new framework or programming paradigm or language. Re-expressing the same intent over and over is so cumbersome. Why is code not simply data types related to each other through functions? The names that Haskell seems to come up with for things seems to be so much dross, and anything but simple.

Anyway, I'm incredibly interested. I'd like to cut out repeating the same thing over and over and over.

— Reply to this email directly or view it on GitHub https://github.com/agocorona/MFlow/issues/62#issuecomment-109568230.

Alberto.

Yes, aware of the various Haskell interfaces with React, but none of them really connect in a similarly intuitive way that Reagent does (normal react isn't very good). Not particuliarly married to React, by the way, as a rendering engine, it just removes a lot of the incidental complexity of ensuring the DOM is synced up correctly with the code. There are some other ideas such as freagent which throws off the react shackles, using a spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're software transactional memory chunks) and keeps the state synchronisation by using cursors (functional windows into a small section of a big pile of state stored in these atoms). This way of dealing with state seems quite neat, and STM is amazingly awesome.

Effectively in reactive, everything keeps up to date whenever anything is changed. Events are driven through channels (which are message queues), and there is one-way data flow. All data is immutible because of clojure. This is the way the facebook team are slowly driving towards anyway, but the clojurescript people have a bit of a leg up on the JS people, I think.

Now, functional relational is something else entirely...

You can read about functional relational here: http://shaffner.us/cs/papers/tarpit.pdf though in general it seems "coding" is gluing a bunch of descriptions of data together, similarly to how Haskell declares a bunch of types, except that the descriptions of the data are glued with relations, which makes a lot of sense. Haskell doesn't really do that. For example, you have a list of customers, and you use a list of male customers, then you don't have to write a function, the male customers are a filtered view on the customers. The "male customers" "type" is defined in terms of the customers "type". It looks like a very beautiful way to program. Unfortunately there aren't any languages that use it... except maybe cascalog. I'd very much like something like that but with Haskell... because, while clojure is beautiful, I constantly find myself wishing for types and a typechecker (and clojure's core.typed syntax is not pleasant). Essentially, I'd like to create a flexible language to express various things in, that I never want to have to re-express again.

Do note that Functional Relational is NOT Functional Reactive. ReactJS is primarily reactive.

Your appraisal of reactive is interesting, but it's not the day to day experience of using Reagent or any of the other client side clojure(script) frameworks. Because clojure has core.async, (http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this separates component communication and allows for composability and one-way data flow. It seems a core.async is similar to what you're stipulating in your "EDSL for hard-working IT programmers" post. This is very good, and quite complex "under the hood" from what I understand. Your EDSL sounded like it was actually much simpler?

The trouble with Clojure, though, are that it's not lazy enough: EVERYTHING is lazy and super-declarative in Haskell. The concurrency story is a little bothering, (very manual) but perhaps that's inevitable. It's also a little bothering that one can't modify programs as they're running in Haskell, or perhaps this is mistake. This would preclude live coding.

Aside from all of this, it seems your code is only intuitive to a Haskeller, sadly.

I'd like to talk more with you about it, and understand more and learn more, and perhaps contribute to some of the documentation if it's a good fit for what I'd like to do.

So far all of the front-side Haskell stuff that I've noticed is about getting haskell to write Javascript and this is awful.

Perhaps there's a better place than here that we could talk about this stuff ongoing?

Sorry for the delay. I have been busy. Tomorrow I will ask you.

2015-06-06 16:05 GMT+02:00 JulianLeviston notifications@github.com:

Yes, aware of the various Haskell interfaces with React, but none of them really connect in a similarly intuitive way that Reagent does (normal react isn't very good). Not particuliarly married to React, by the way, as a rendering engine, it just removes a lot of the incidental complexity of ensuring the DOM is synced up correctly with the code. There are some other ideas such as freagent which throws off the react shackles, using a spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're software transactional memory chunks) and keeps the state synchronisation by using cursors (functional windows into a small section of a big pile of state stored in these atoms). This way of dealing with state seems quite neat, and STM is amazingly awesome.

Effectively in reactive, everything keeps up to date whenever anything is changed. Events are driven through channels (which are message queues), and there is one-way data flow. All data is immutible because of clojure. This is the way the facebook team are slowly driving towards anyway, but the clojurescript people have a bit of a leg up on the JS people, I think.

Now, functional relational is something else entirely...

You can read about functional relational here: http://shaffner.us/cs/papers/tarpit.pdf though in general it seems "coding" is gluing a bunch of descriptions of data together, similarly to how Haskell declares a bunch of types, except that the descriptions of the data are glued with relations, which makes a lot of sense. Haskell doesn't really do that. For example, you have a list of customers, and you use a list of male customers, then you don't have to write a function, the male customers are a filtered view on the customers. The "male customers" "type" is defined in terms of the customers "type". It looks like a very beautiful way to program. Unfortunately there aren't any languages that use it... except maybe cascalog. I'd very much like something like that but with Haskell... because, while clojure is beautiful, I constantly find myself wishing for types and a typechecker (and clojure's core.typed syntax is not pleasant). E ssentially, I'd like to create a flexible language to express various things in, that I never want to have to re-express again.

Do note that Functional Relational is NOT Functional Reactive. ReactJS is primarily reactive.

Your appraisal of reactive is interesting, but it's not the day to day experience of using Reagent or any of the other client side clojure(script) frameworks. Because clojure has core.async, ( http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this separates component communication and allows for composability and one-way data flow. It seems a core.async is similar to what you're stipulating in your "EDSL for hard-working IT programmers" post. This is very good, and quite complex "under the hood" from what I understand. Your EDSL sounded like it was actually much simpler?

The trouble with Clojure, though, are that it's not lazy enough: EVERYTHING is lazy and super-declarative in Haskell. The concurrency story is a little bothering, (very manual) but perhaps that's inevitable. It's also a little bothering that one can't modify programs as they're running in Haskell, or perhaps this is mistake. This would preclude live coding.

Aside from all of this, it seems your code is only intuitive to a Haskeller, sadly.

I'd like to talk more with you about it, and understand more and learn more, and perhaps contribute to some of the documentation if it's a good fit for what I'd like to do.

So far all of the front-side Haskell stuff that I've noticed is about getting haskell to write Javascript and this is awful.

— Reply to this email directly or view it on GitHub https://github.com/agocorona/MFlow/issues/62#issuecomment-109581855.

Alberto.

Finally I´m free to answer you:

2015-06-06 16:05 GMT+02:00 JulianLeviston notifications@github.com:

Yes, aware of the various Haskell interfaces with React, but none of them really connect in a similarly intuitive way that Reagent does (normal react isn't very good). Not particuliarly married to React, by the way, as a rendering engine, it just removes a lot of the incidental complexity of ensuring the DOM is synced up correctly with the code. There are some other ideas such as freagent which throws off the react shackles, using a spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're software transactional memory chunks) and keeps the state synchronisation by using cursors (functional windows into a small section of a big pile of state stored in these atoms). This way of dealing with state seems quite neat, and STM is amazingly awesome.

Effectively in reactive, everything keeps up to date whenever anything is changed. Events are driven through channels (which are message queues), and there is one-way data flow. All data is immutible because of clojure. This is the way the facebook team are slowly driving towards anyway, but the clojurescript people have a bit of a leg up on the JS people, I think.

I though that react just bubble up the events to the top of the widget, then generate all the rendering and a diff engine detect the changes, then apply the changes to the rendering.

Now, functional relational is something else entirely...

You can read about functional relational here: http://shaffner.us/cs/papers/tarpit.pdf though in general it seems "coding" is gluing a bunch of descriptions of data together, similarly to how Haskell declares a bunch of types, except that the descriptions of the data are glued with relations, which makes a lot of sense. Haskell doesn't really do that. For example, you have a list of customers, and you use a list of male customers, then you don't have to write a function, the male customers are a filtered view on the customers. The "male customers" "type" is defined in terms of the customers "type". It looks like a very beautiful way to program. Unfortunately there aren't any languages that use it... except maybe cascalog. I'd very much like something like that but with Haskell... because, while clojure is beautiful, I constantly find myself wishing for types and a typechecker (and clojure's core.typed syntax is not pleasant). E ssentially, I'd like to create a flexible language to express various things in, that I never want to have to re-express again.

I read this paper very shallowly before sending the last reply. I found it following some links. I will read it in more detail but basically what you say is what I though. It is nice but honestly I think that the idea behind hplayground is better. why? because it is composable. each widget is a single expression that is combined with others. no other seaming is necessary. That non composability was the problem of every kind of GUI invented, including the web browser.

Do note that Functional Relational is NOT Functional Reactive. ReactJS is primarily reactive.

I really dont't know what is reactive. People today adscribe to reactive almost anything. publish-suscribe frameworks now are called reactive. impure effects are called functional pure and reactive. It is better not to use the word reactive. it is almost meaningless.

Your appraisal of reactive is interesting, but it's not the day to day experience of using Reagent or any of the other client side clojure(script) frameworks. Because clojure has core.async, ( http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this separates component communication and allows for composability and one-way data flow. It seems a core.async is similar to what you're stipulating in your "EDSL for hard-working IT programmers" post. This is very good, and quite complex "under the hood" from what I understand. Your EDSL sounded like it was actually much simpler?

Yes it is somehow related with my article that you mention. both hplayground and the EDSL share the same principle that is basically a simpler way to deal with continuations. in hplayground , when an event arrives, the event continues the rest of the code , render the part of the widget affected by the event. events can happen anywhere in the program sequence while in react.js only can happen at the top level of the widget, so it need to execute it fully, detect the changes etc. in transient, when an asynchronous event, like the reception of a file is finished, it trigger the continuation as well. The mechanism is the same. The advantage is that this does not need special constructions. It is like programming console applications. It makes asyncronnous as easy to program as synchronous and equally readable.

I watched the slides of a presentation of core.async and it solves some problems but I think that my EDSL solve a wider kind of problems

The trouble with Clojure, though, are that it's not lazy enough: EVERYTHING is lazy and super-declarative in Haskell. The concurrency story is a little bothering, (very manual) but perhaps that's inevitable. It's also a little bothering that one can't modify programs as they're running in Haskell, or perhaps this is mistake. This would preclude live coding.

well my EDSL edit the continuations while it is executing in some way. I used it to re execute certain registered statement when some primitive "goback" is called. This is intended to undo transactions. There are some limited examples of live coding in Haskell in youtube. The interpreter is very fast and can simulate it, although not as well as clojure..

Aside from all of this, it seems your code is only intuitive to a Haskeller, sadly.

It is like a console application! there are no interruptions of the flow, no event handlers. Perhaps you are puzzled by the operators <|> <*> They are standard haskell operations.

For example, a <|> b return either the result of 'a' or the one of 'b' if 'a' produces an invalid result (in this case, if 'a' finish with empty or stop)

I'd like to talk more with you about it, and understand more and learn more, and perhaps contribute to some of the documentation if it's a good fit for what I'd like to do.

Very good. I would be very happy to talk with you!

So far all of the front-side Haskell stuff that I've noticed is about getting haskell to write Javascript and this is awful.

— Reply to this email directly or view it on GitHub https://github.com/agocorona/MFlow/issues/62#issuecomment-109581855.

Alberto.

Well, my email address is "kvmjboAmfwjtupo/ofu" if you subtract 1 from each of the ASCII codes for the characters. Drop me a line and we can discuss further via email.

My point was simply that Haskell is not very intuitive or easy to people who haven't studied it. Contrast this to Ruby or Python, which almost read like English a lot of the time. (I'm not making a case for or against anything here, it's simply an observation about what is "easy" to the average person who doesn't know any of these languages).

agocorona / MFlow

Still going? Documentation #62