The Good, the Bad and the GUI

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

The Good, the Bad and the GUI

Wojtek Narczyński
Dear All,

Haskell is great for great many areas, let me name just two: - parsers,
translators, interpreters, compilers; highly concurrent systems.

Haskell is however not great for GUIs. I've been thinking a little why
this is so. I think one of the reasons might be that in Haskell it is
unusual to deal with data that is incomplete or otherwise erroneous. Let
me try to explain, what I mean, by example. If you declare Person class
in Java, you automatically get a thingy that you can readily use in UI
construction, because all the fields can temporarily be null, even the
required ones. In Haskell you'd need two data types: the usual proper
Haskell data type, and another which wraps every field in Maybe,
facilitates editing, validation, etc. Perhaps it would be possible to
generate one data type from the other, or generate both from a common
specification.

Let me write the same thing in other words. It is not controversial to
say on this list that specifying what is correct means, is a good idea.
But for GUIs, in addition to the strong type, you need another relaxed
type to hold the values temporarily, until the human manages to deliver
correct data, often by trial and error.

Comments welcome.

--
Kind regards,
Wojtek Narczyński

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Brandon Allbery
On Mon, Aug 11, 2014 at 6:16 PM, Wojtek Narczyński <[hidden email]> wrote:
Let me write the same thing in other words. It is not controversial to say on this list that specifying what is correct means, is a good idea. But for GUIs, in addition to the strong type, you need another relaxed type to hold the values temporarily, until the human manages to deliver correct data, often by trial and error.

I think there are far larger issues to deal with first: you need to have a sensible connection from Haskell to a GUI before you can worry about getting data across it. At the moment, we have either mostly procedural interfaces to common procedural toolkits (WxHaskell, gtk2hs) or a number of still largely experimental FRP interfaces.

It is not particularly difficult to deal with the step that you highlight once we have solved the basic interface to the GUI; you can do it with Template Haskell, or generics, or lens, or with semi-typed interfaces between Haskell and the GUI (for example, I can see Aeson sitting in this layer). But figuring out how to work it in depends on knowing what we're working it into.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona
I think that the GUI people hace to embrace the formlet concept, used in HTML interfaces sooner better than later. The GUI development has lost the train by trying to interface C libraries that are decades old. The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.


2014-08-12 0:25 GMT+02:00 Brandon Allbery <[hidden email]>:
On Mon, Aug 11, 2014 at 6:16 PM, Wojtek Narczyński <[hidden email]> wrote:
Let me write the same thing in other words. It is not controversial to say on this list that specifying what is correct means, is a good idea. But for GUIs, in addition to the strong type, you need another relaxed type to hold the values temporarily, until the human manages to deliver correct data, often by trial and error.

I think there are far larger issues to deal with first: you need to have a sensible connection from Haskell to a GUI before you can worry about getting data across it. At the moment, we have either mostly procedural interfaces to common procedural toolkits (WxHaskell, gtk2hs) or a number of still largely experimental FRP interfaces.

It is not particularly difficult to deal with the step that you highlight once we have solved the basic interface to the GUI; you can do it with Template Haskell, or generics, or lens, or with semi-typed interfaces between Haskell and the GUI (for example, I can see Aeson sitting in this layer). But figuring out how to work it in depends on knowing what we're working it into.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński

On 12.08.2014 00:53, Alberto G. Corona wrote:
> I think that the GUI people hace to embrace the formlet concept, used
> in HTML interfaces sooner better than later. The GUI development has
> lost the train by trying to interface C libraries that are decades
> old. The reactive solutions complicates the problem rather than to
> simplify it. That means that they are not the correct paradigm.
>
I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
explicitly upfront.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona
Wojtek. What you say is exactly what has been solved time ago by fomlets in Web interfaces.  There are many formlet library and almost all haskell web framework use formlets.


2014-08-12 0:57 GMT+02:00 Wojtek Narczyński <[hidden email]>:

On 12.08.2014 00:53, Alberto G. Corona wrote:
I think that the GUI people hace to embrace the formlet concept, used in HTML interfaces sooner better than later. The GUI development has lost the train by trying to interface C libraries that are decades old. The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it explicitly upfront.



--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Tikhon Jelvis
In reply to this post by Wojtek Narczyński
For the original question: take a look at functional reactive programming (FRP). It takes a slightly different approach to the whole GUI problem, but, I've found, obviates some of your issues.

You can quickly play around with FRP and HTML UIs by using threepenny-gui and Reactive Banana. The former is a simple UI framework that lets you create and interact with HTML in Haskell, and the latter in a nice library for FRP. They work well together:

http://apfelmus.nfshost.com/blog/2013/08/02-reactive-banana-threepenny.html

There's a nice tutorial about FRP and Reactive Banana you can read on the Haskell Wiki. I haven't had the chance to go through it myself, but it looks promising.

http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana

If you're wondering about Haskell and UIs, I think FRP is the best place to look—it provides the most pleasant semantics for programming UIs that I've come across, although most of the libraries are still a bit experimental. (Implementing the exact semantics we'd like turned out to be very difficult!)

> The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

That's a very hasty, superficial way to dismiss a whole paradigm!

FRP libraries have proven *difficult to implement*, but this does not mean they somehow "complicate the problem". The real insight with FRP is developing a nice semantics *for the end user* and making it simpler to work with the libraries, at the expense of a more complex implementation. It's a parallel to functional programming at large: we're willing to trade complexity in GHC in return for a nicer high-level programming environment.

Formlets are an interesting concept, but they seem to be significantly more narrow than FRP. How do formlets address continuous things like animations or mouse movement?

Also, a lot of the examples (at least on the Haskell wiki[1]) seem pretty amenable to FRP. How is
 
    chooseBool :: Form Bool
    chooseBool = enumRadio [(True, "Yes"), (False, "No")] True

significantly different from just providing a Behavior Bool in the spirit of FRP?


On Mon, Aug 11, 2014 at 3:57 PM, Wojtek Narczyński <[hidden email]> wrote:

On 12.08.2014 00:53, Alberto G. Corona wrote:
I think that the GUI people hace to embrace the formlet concept, used in HTML interfaces sooner better than later. The GUI development has lost the train by trying to interface C libraries that are decades old. The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it explicitly upfront.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona
In reply to this post by Alberto G. Corona
But formlets are implemented in the server side.  and you probably think in applications with heavy use of JavaScript for validations, interaction  etc. In this case, there is a formlet implementation in the client side, which is my.. Ahem!... package hplaygroud:



2014-08-12 1:14 GMT+02:00 Alberto G. Corona <[hidden email]>:
Wojtek. What you say is exactly what has been solved time ago by fomlets in Web interfaces.  There are many formlet library and almost all haskell web framework use formlets.


2014-08-12 0:57 GMT+02:00 Wojtek Narczyński <[hidden email]>:


On 12.08.2014 00:53, Alberto G. Corona wrote:
I think that the GUI people hace to embrace the formlet concept, used in HTML interfaces sooner better than later. The GUI development has lost the train by trying to interface C libraries that are decades old. The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it explicitly upfront.



--
Alberto.



--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Richard A. O'Keefe
In reply to this post by Wojtek Narczyński
> If you declare Person class
> in Java, you automatically get a thingy that you can readily use in UI
> construction, because all the fields can temporarily be null, even the
> required ones. In Haskell you'd need two data types: the usual proper
> Haskell data type, and another which wraps every field in Maybe,
> facilitates editing, validation, etc. Perhaps it would be possible to
> generate one data type from the other, or generate both from a common
> specification.

You seem to be referring to the "incompletely initialised object"
anti-pattern.  The books I have about concurrency in Java/on the JVM
strongly recommend making Java objects immutable when you can.

Even in Visual Basic, if an object is "constructed" via a lengthy
sequence of steps, it is good design to distinguish between two
different things": a fully constructed Foo object and a FooBuilder
object.  Sometimes they need to be the same object, but there really
do need to be two *interfaces*.  Once past the construction phase,
you want to KNOW that the object is fully constructed, and there are
things the constructor might do that you DON'T want other objects to
do.

Reflecting on the use case you are talking about, it seems to be
that there are two conceptually very distinct objects here.
There is a FooForm object which is intimately connected to the
user interface and may only partially describe a Foo, and there
is a Foo object which is *not* connected to the user interface
or if it is, is connected in a quite different way, exposing
quite different behaviours.  Reflecting further, suppose I fill
out a form and press a button to commit this object, then I
edit the form to be a little different, and press the button
again.  Creating a new *object* by revising a single *form* is
clearly distinct from *editing* an existing object.

What I think about this, therefore, is that you want a clear
distinction between FooForms and Foos (at the very minimum a
distinction between FooForm and Foo interfaces) no matter WHAT
kind of programming language you are using, and I don't see
Haskell as anything special here.

> Let me write the same thing in other words. It is not controversial to
> say on this list that specifying what is correct means, is a good idea.
> But for GUIs, in addition to the strong type, you need another relaxed
> type to hold the values temporarily, until the human manages to deliver
> correct data, often by trial and error.

In short, we agree, that is indeed *ANOTHER* type.

Not only may a FooForm not yet hold information a Foo needs,
a FooForm may hold information that a Foo does *not* need.
For example, a FooForm might need to hold on to some credentials
to prove that it is authorised to create Foo objects, whereas a
Foo object might not.

In Smalltalk, Java, C#, &c one might look at ways of automatically
constructing FooForms from Foo classes + annotations.  Using some
sort of generic processing, one could also do this in Haskell.
Having two classes/types does not have to be twice as much work.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński
On 12.08.2014 05:31, [hidden email] wrote:

>> If you declare Person class
>> in Java, you automatically get a thingy that you can readily use in UI
>> construction, because all the fields can temporarily be null, even the
>> required ones. In Haskell you'd need two data types: the usual proper
>> Haskell data type, and another which wraps every field in Maybe,
>> facilitates editing, validation, etc. Perhaps it would be possible to
>> generate one data type from the other, or generate both from a common
>> specification.
> You seem to be referring to the "incompletely initialised object"
> anti-pattern.  The books I have about concurrency in Java/on the JVM
> strongly recommend making Java objects immutable when you can.
>
> Even in Visual Basic, if an object is "constructed" via a lengthy
> sequence of steps, it is good design to distinguish between two
> different things": a fully constructed Foo object and a FooBuilder
> object.  Sometimes they need to be the same object, but there really
> do need to be two *interfaces*.  Once past the construction phase,
> you want to KNOW that the object is fully constructed, and there are
> things the constructor might do that you DON'T want other objects to
> do.

Take a VAT Invoice as an example. You will have:

Invoice, InvoiceBuilder,
InvoiceLineItem, InvoiceLineItemBuilder,
InvoiceCustomer, InvoiceCustomerBuilder,
InvoiceSummary, (no Builder, as this is calculated)
(many, many more classes in a realistic system)

Now, where the rather complex validation belongs? Optional / mandatory
requirements, lengths, ranges, regexps, control sums, field
interdependencies, autocompletes, server sent notifications? Where to
put all of this? To regular classes, to builder classes, or to both?

--
Wojtek
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Jim Stuttard-2

On 08/12/2014 08:55 AM, Wojtek Narczyński wrote:

> On 12.08.2014 05:31, [hidden email] wrote:
>>> If you declare Person class
>>> in Java, you automatically get a thingy that you can readily use in UI
>>> construction, because all the fields can temporarily be null, even the
>>> required ones. In Haskell you'd need two data types: the usual proper
>>> Haskell data type, and another which wraps every field in Maybe,
>>> facilitates editing, validation, etc. Perhaps it would be possible to
>>> generate one data type from the other, or generate both from a common
>>> specification.
>> You seem to be referring to the "incompletely initialised object"
>> anti-pattern. The books I have about concurrency in Java/on the JVM
>> strongly recommend making Java objects immutable when you can.
>>
>> Even in Visual Basic, if an object is "constructed" via a lengthy
>> sequence of steps, it is good design to distinguish between two
>> different things": a fully constructed Foo object and a FooBuilder
>> object. Sometimes they need to be the same object, but there really
>> do need to be two *interfaces*. Once past the construction phase,
>> you want to KNOW that the object is fully constructed, and there are
>> things the constructor might do that you DON'T want other objects to
>> do.
>
> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs? Optional / mandatory
> requirements, lengths, ranges, regexps, control sums, field
> interdependencies, autocompletes, server sent notifications? Where to
> put all of this? To regular classes, to builder classes, or to both?
These sound like cross-cutting concerns. I found this paper on monads
and mixins for AOP.

http://i.cs.hku.hk/~bruno/papers/MixinAspects.pdf

hth

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński
In reply to this post by Alberto G. Corona
On 12.08.2014 01:14, Alberto G. Corona wrote:
> Wojtek. What you say is exactly what has been solved time ago by
> fomlets in Web interfaces.  There are many formlet library and almost
> all haskell web framework use formlets.
>
AFAIK, formlets at the server are very much like PHP, only with neater
syntax, strong typing, and the like. Formlets tutorials teach you to put
all your validation into the GUI, you really can't do much worse.

But, Alberto, your client side formlets look very interesting. I printed
your Monad.Reader paper, and I'm definitely going to explore your ideas.

--
Kind regards,
Wojtek Narczyński
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Chris Warburton
In reply to this post by Wojtek Narczyński
Wojtek Narczyński <[hidden email]> writes:

> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs? Optional / mandatory
> requirements, lengths, ranges, regexps, control sums, field
> interdependencies, autocompletes, server sent notifications? Where to
> put all of this? To regular classes, to builder classes, or to both?

The current trend in OOP Web frameworks Model-View-Controller.

In MVP, Invoice/InvoiceLineItem/InvoiceCustomer/InvoiceSummary/etc. are
the Model: they should form a standalone 'simulation' of an Invoice,
without concerning themselves with 'external' aspects.

Validation, bootstrapping (builders), etc. live in the Controller
layer.

If the server notifications are informing the user about the behaviour
of the Model, they're part of the View. If they facilitate interaction
they're part of the Controller.

There are many functional styles which suit Models:
 - The pseudo-imperative style of Applicative/Monad/Arrow/etc.
 - The 'interacting streams' style, eg. infinite [(Request, Response)]
   lists.
 - Functional Reactive Programming

Since Controllers can't mutate Models in Haskell, they must do one of
two things:
 - Influence some 'future' behaviour of the Model, eg. using FRP
 - Build a new Model from the given settings

To me the latter choice looks similar to a parsing problem. You say that
Haskell's "great" at parsing, which I think contradicts your statement
that "in Haskell it is unusual to deal with data that is incomplete or
otherwise erroneous".

In Haskell we deal with incomplete data all the time using lazy
evaluation. Erroneous data doesn't require Maybes all over our data: it
just needs one big Maybe in the 'parsing' function; or, more likely,
"Either [Error]" detailing the problems which were found.

Views are straightforward: recurse over the data, use FRP, etc.

Cheers,
Chris
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona
In reply to this post by Tikhon Jelvis



2014-08-12 1:21 GMT+02:00 Tikhon Jelvis <[hidden email]>:
For the original question: take a look at functional reactive programming (FRP). It takes a slightly different approach to the whole GUI problem, but, I've found, obviates some of your issues.

You can quickly play around with FRP and HTML UIs by using threepenny-gui and Reactive Banana. The former is a simple UI framework that lets you create and interact with HTML in Haskell, and the latter in a nice library for FRP. They work well together:

http://apfelmus.nfshost.com/blog/2013/08/02-reactive-banana-threepenny.html

There's a nice tutorial about FRP and Reactive Banana you can read on the Haskell Wiki. I haven't had the chance to go through it myself, but it looks promising.

http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana

If you're wondering about Haskell and UIs, I think FRP is the best place to look—it provides the most pleasant semantics for programming UIs that I've come across, although most of the libraries are still a bit experimental. (Implementing the exact semantics we'd like turned out to be very difficult!)

> The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

That's a very hasty, superficial way to dismiss a whole paradigm!

Yes!

 I was just trying to be a bit provoking. Sorry.

The objections about the use of  current FRP models for GUIs are here:


and here:


Allthough FRP is too wide. Monadic FRP is more appropriate for GUIs for the same reasons.  hplayground uses monadic FRP + formlets


FRP libraries have proven *difficult to implement*, but this does not mean they somehow "complicate the problem". The real insight with FRP is developing a nice semantics *for the end user* and making it simpler to work with the libraries, at the expense of a more complex implementation. It's a parallel to functional programming at large: we're willing to trade complexity in GHC in return for a nicer high-level programming environment.

Formlets are an interesting concept, but they seem to be significantly more narrow than FRP. How do formlets address continuous things like animations or mouse movement?

Also, a lot of the examples (at least on the Haskell wiki[1]) seem pretty amenable to FRP. How is
 
    chooseBool :: Form Bool
    chooseBool = enumRadio [(True, "Yes"), (False, "No")] True

significantly different from just providing a Behavior Bool in the spirit of FRP?


On Mon, Aug 11, 2014 at 3:57 PM, Wojtek Narczyński <[hidden email]> wrote:

On 12.08.2014 00:53, Alberto G. Corona wrote:
I think that the GUI people hace to embrace the formlet concept, used in HTML interfaces sooner better than later. The GUI development has lost the train by trying to interface C libraries that are decades old. The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it explicitly upfront.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Aloïs Cochard
In reply to this post by Wojtek Narczyński
I think the way Jon Sterling integrated validation in his extensible library might give some inspiration about using a similar approach to solve the specific problem you describe.

He did a great talk about it recently, I highly recommend it:

Cheers

Alois



On 11 August 2014 23:16, Wojtek Narczyński <[hidden email]> wrote:
Dear All,

Haskell is great for great many areas, let me name just two: - parsers, translators, interpreters, compilers; highly concurrent systems.

Haskell is however not great for GUIs. I've been thinking a little why this is so. I think one of the reasons might be that in Haskell it is unusual to deal with data that is incomplete or otherwise erroneous. Let me try to explain, what I mean, by example. If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.

Let me write the same thing in other words. It is not controversial to say on this list that specifying what is correct means, is a good idea. But for GUIs, in addition to the strong type, you need another relaxed type to hold the values temporarily, until the human manages to deliver correct data, often by trial and error.

Comments welcome.

--
Kind regards,
Wojtek Narczyński

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



--

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona
In reply to this post by Wojtek Narczyński



2014-08-12 10:31 GMT+02:00 Wojtek Narczyński <[hidden email]>:
On 12.08.2014 01:14, Alberto G. Corona wrote:
Wojtek. What you say is exactly what has been solved time ago by fomlets in Web interfaces.  There are many formlet library and almost all haskell web framework use formlets.

AFAIK, formlets at the server are very much like PHP, only with neater syntax, strong typing, and the like. Formlets tutorials teach you to put all your validation into the GUI, you really can't do much worse.

I think that this horizontal separating the GUI from his application logic is a wrong conception of separation of concern.. as strange as it may sound, since that makes applications and components non composable. The MVC model is non composable!

A better separation of concern, for many purposes, is the vertical one in which each functionality include its own interface, logic and data model. The obstacle for implementing this kind of separation of concern is mainly technological, because each of the three layes uses different languages, so an horizontal separation is easier. But it is not appropriate for most purposes. It is very bad for creating GUIs!!




 

But, Alberto, your client side formlets look very interesting. I printed your Monad.Reader paper, and I'm definitely going to explore your ideas.
 
Thanks! 


--
Kind regards,
Wojtek Narczyński



--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński
In reply to this post by Chris Warburton
W dniu 2014-08-12 11:30, Chris Warburton pisze:
> Wojtek Narczyński<[hidden email]>  writes:
>
>> ut all of this? To regular classes, to builder classes, or to both?
> The current trend in OOP Web frameworks Model-View-Controller.
We've been doing this for 15 years, and believe me, it works only so-so.
> To me the latter choice looks similar to a parsing problem. You say that
> Haskell's "great" at parsing, which I think contradicts your statement
> that "in Haskell it is unusual to deal with data that is incomplete or
> otherwise erroneous".
Grammars have been tried for GUIs, without any success. I'm not aware of
any even moderate size GUI constructed this way.
> In Haskell we deal with incomplete data all the time using lazy
> evaluation. Erroneous data doesn't require Maybes all over our data: it
> just needs one big Maybe in the 'parsing' function; or, more likely,
> "Either [Error]" detailing the problems which were found.
>
Continuing my VAT Invoice example, let us say a LineItem that does not
have a product description (missing value), but it does have all the
numeric fields filled in.  It is partly erroneous, but it can be
included in calculation of the total. How would you handle it with
Either [Error] Invoice style code?

--
Cheers,
Wojtek Narczyński
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Alberto G. Corona



2014-08-12 12:46 GMT+02:00 Wojtek Narczyński <[hidden email]>:
W dniu 2014-08-12 11:30, Chris Warburton pisze:
Wojtek Narczyński<[hidden email]>  writes:


ut all of this? To regular classes, to builder classes, or to both?
The current trend in OOP Web frameworks Model-View-Controller.
We've been doing this for 15 years, and believe me, it works only so-so.

To me the latter choice looks similar to a parsing problem. You say that
Haskell's "great" at parsing, which I think contradicts your statement
that "in Haskell it is unusual to deal with data that is incomplete or
otherwise erroneous".
Grammars have been tried for GUIs, without any success. I'm not aware of any even moderate size GUI constructed this way.

Well, a formlet is essentially an applicative parser of HTTP parameters + a writer of HTML code. it works pretty well. and it can create the complete logic of a page, not only the interface  if we add a monadic instance.
 
In Haskell we deal with incomplete data all the time using lazy
evaluation. Erroneous data doesn't require Maybes all over our data: it
just needs one big Maybe in the 'parsing' function; or, more likely,
"Either [Error]" detailing the problems which were found.

Continuing my VAT Invoice example, let us say a LineItem that does not have a product description (missing value), but it does have all the numeric fields filled in.  It is partly erroneous, but it can be included in calculation of the total. How would you handle it with Either [Error] Invoice style code?

--
Cheers,
Wojtek Narczyński

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński
In reply to this post by Alberto G. Corona
On 12.08.2014 11:40, Alberto G. Corona wrote:

> The reactive solutions complicates the problem rather than to simplify it. That means that they are not the correct paradigm.

That's a very hasty, superficial way to dismiss a whole paradigm!

Yes!

I was just trying to be a bit provoking. Sorry.


I would really like to see a complex web form (think Facebook, VAT Invoice, Tax forms) done in FRP. The harsh reality is that FRP for GUIs still has to prove that its utility reaches beyond the game of Pong.

--
Wojtek

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Daniel Gorín
In reply to this post by Wojtek Narczyński

On 11 Aug 2014, at 23:16, Wojtek Narczyński <[hidden email]> wrote:

> If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.

At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:

data Person f
  = Person {
    firstName :: f String
  ,lastName :: f String
  ,birthDate :: f Date
  ,height :: f Int
  }

Then you get:

 - "Person Id" is a person with every field set in stone.

 - "Person Maybe" is a person with missing information.

 - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Good, the Bad and the GUI

Wojtek Narczyński
In reply to this post by Alberto G. Corona
W dniu 2014-08-12 01:22, Alberto G. Corona pisze:
> But formlets are implemented in the server side.  and you probably
> think in applications with heavy use of JavaScript for validations,
> interaction  etc. In this case, there is a formlet implementation in
> the client side, which is my.. Ahem!... package hplaygroud:
>
> https://github.com/agocorona/hplayground
>
Very interesting, please allow a few questions about your approach:

1. Would it be possible to save a snapshot of a paritally filled form on
the server?
2. Would it be possible to display the sum before the values: 3 = [ 1] +
[  2] <-- this is rendered HTML, not Haskell?

(I thought I would have more questions, but somehow I can't think of any
right now...)

--
Kind regards,
Wojtek
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234