[Haskell-cafe] The Good, the Bad and the GUI
Alberto G. Corona
agocorona at gmail.com
Tue Aug 12 10:54:05 UTC 2014
2014-08-12 12:46 GMT+02:00 Wojtek Narczyński <wojtek at power.com.pl>:
> W dniu 2014-08-12 11:30, Chris Warburton pisze:
>> Wojtek Narczyński<wojtek at power.com.pl> 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?
> Wojtek Narczyński
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe