Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generate semi-dynamic UIs with Haskell

github.com

Post reply on HN
Print view View original

1–10 of 16 posts

Re: Generate semi-dynamic UIs with Haskell

#3

Post by dmitriid »

I simply love it how every single Haskell framework I've seen that has "ease of development" and "it's easy" and similar immediately devolves from this (from Concur's docs [1]):

  hello = do
    button [onClick] [text "Say Hello"]
    text "Hello Sailor!"
into this:

  inputWidget = input [(Changed  onChange, Focused
or this:

  inputWidget st = input [st {focusCount = st.focusCount+1}  st {currentText = s})  onChange]
for even the slightest modifications (which are not even complex in this case)

  These instances, allow a natural handling of 
  return values using , ,
Right...

[1] https://github.com/ajnsit/concur-documentation/blob/master/R...

Re: Generate semi-dynamic UIs with Haskell

#4

Post by ivanbakel »

Cool application of Haskell's purity-by-default. I'm slightly surprised this takes the approach of enumerating the whole input space to get all states, though - given that termination for big spaces isn't a priority, why not just explore all paths instead? Then you could return `Int` as much as you wanted, if the actual code only goes through finitely many different values.

Re: Generate semi-dynamic UIs with Haskell

#5

Post by pka »

ivanbakel wrote: post #4

Cool application of Haskell's purity-by-default. I'm slightly surprised this takes the approach of enumerating the whole input space to get all states, though - given that termination for big spaces isn't a priority, why not just explore all paths instead? Then you could return `Int` as much as you wanted, if the actual code only goes through finitely many different values.

> why not just explore all paths instead?

Author here.

The problem is that concur-static generates static JS code that encodes all possible UI state transitions - so if the state space is big or infinite, so will be the resulting generated JS.

I wanted to explore the viability of generating simple static UIs with some level of dynamism. concur-static is definitely not intended as a replacement for full-blown client side UI libraries/frameworks.

Re: Generate semi-dynamic UIs with Haskell

#6

Post by ivanbakel »

pka wrote: post #5
ivanbakel wrote: post #4

Cool application of Haskell's purity-by-default. I'm slightly surprised this takes the approach of enumerating the whole input space to get all states, though - given that termination for big spaces isn't a priority, why not just explore all paths instead? Then you could return `Int` as much as you wanted, if the actual code only goes through finitely many different values.

> why not just explore all paths instead? Author here. The problem is that concur-static generates static JS code that encodes all possible UI state transitions - so if the state space is big or infinite, so will be the resulting generated JS. I wanted to explore the viability of generating simple static UIs with some level of dynamism. concur-static is definitely not intended as a replacement for full-blown client s…

> so if the state space is big or infinite, so will be the resulting generated JS.

I understand that, but it's not like this doesn't already choke on big input spaces. Why not allow me to use a big input space with a small state space by exploring the state space instead? Otherwise you just seem to be exploiting the fact that small input spaces make for small state spaces, which seems like an unnecessary indirection.

Or is it to try to enforce small state spaces to prevent programmer error?

Re: Generate semi-dynamic UIs with Haskell

#7

Post by chrissoundz »

dmitriid wrote: post #3

I simply love it how every single Haskell framework I've seen that has "ease of development" and "it's easy" and similar immediately devolves from this (from Concur's docs [1]): hello = do button [onClick] [text "Say Hello"] text "Hello Sailor!" into this: inputWidget = input [(Changed onChange, Focused or this: inputWidget st = input [st {focusCount = st.focusCount+1} st {currentText = s}) onChange] for even the sli…

It's not clear to me what you're trying to show? Are you saying the later examples look more complex?

Re: Generate semi-dynamic UIs with Haskell

#8

Post by pka »

ivanbakel wrote: post #6
pka wrote: post #5

Earlier quoted context omitted.

> why not just explore all paths instead? Author here. The problem is that concur-static generates static JS code that encodes all possible UI state transitions - so if the state space is big or infinite, so will be the resulting generated JS. I wanted to explore the viability of generating simple static UIs with some level of dynamism. concur-static is definitely not intended as a replacement for full-blown client s…

> so if the state space is big or infinite, so will be the resulting generated JS. I understand that, but it's not like this doesn't already choke on big input spaces. Why not allow me to use a big input space with a small state space by exploring the state space instead? Otherwise you just seem to be exploiting the fact that small input spaces make for small state spaces, which seems like an unnecessary indirection.…

Ah, I understand now.

That seems like a good idea indeed, however I'm not sure how it'd look in practice. The transition from input space to state space happens in the event handlers, which currently look like this:

    onClick :: Bounded a => Enum a => a -> VDOM a
If I understand correctly, you're proposing something like:

    onClick :: Bounded a => Enum a => a -> VDOM b
Where b can be whatever (i.e. an Int, etc)? How would a be converted into b?

Re: Generate semi-dynamic UIs with Haskell

#9

Post by whateveracct »

chrissoundz wrote: post #7
dmitriid wrote: post #3

I simply love it how every single Haskell framework I've seen that has "ease of development" and "it's easy" and similar immediately devolves from this (from Concur's docs [1]): hello = do button [onClick] [text "Say Hello"] text "Hello Sailor!" into this: inputWidget = input [(Changed onChange, Focused or this: inputWidget st = input [st {focusCount = st.focusCount+1} st {currentText = s}) onChange] for even the sli…

It's not clear to me what you're trying to show? Are you saying the later examples look more complex?

My guess: The latter examples look unfamiliar (looks like Haskell) while the first example looks familiar to the general eye (looks like any PL)

The things being compared don't even have the same purpose so idt comparing them even makes sense /shrug

Re: Generate semi-dynamic UIs with Haskell

#10

Post by dmitriid »

chrissoundz wrote: post #7
dmitriid wrote: post #3

I simply love it how every single Haskell framework I've seen that has "ease of development" and "it's easy" and similar immediately devolves from this (from Concur's docs [1]): hello = do button [onClick] [text "Say Hello"] text "Hello Sailor!" into this: inputWidget = input [(Changed onChange, Focused or this: inputWidget st = input [st {focusCount = st.focusCount+1} st {currentText = s}) onChange] for even the sli…

It's not clear to me what you're trying to show? Are you saying the later examples look more complex?

Of course they do. Of course they are.

The simplest code change turns the code in to a monadic/functor soup.

Post reply on HN