[Haskell-cafe] The Good, the Bad and the GUI

[Wojtek Narczyński]

On 13.08.2014 12:37, Tom Ellis wrote:
> On Tue, Aug 12, 2014 at 12:46:05PM +0200, Wojtek Narczyński wrote:
>> 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?
> What sort of functionality are you looking for exactly?  What's your
> objection to (for example)
>
>      data LineItemGeneral a = LineItem { price :: Price
>                                        , quantity :: Quantity
>                                        , description :: a }
>
>      type LineItem = LineItemGeneral String
>      type LineItemPossiblyIncomplete = LineItemGeneral (Maybe String)
>      type LineItemWithoutDescription = LineItemGeneral ()
>
>      totalValue :: LineItemGeneral a -> Value
>      totalValue lineItem = price lineItem * quantity lineItem
>
> `totalValue` works for all sorts of line items, whether they have a
> description or not.
>
>
Let's say the user entered:

No, Name, Qty, Price
--------------------------------------------
1. [        ]   [99] [10]
2. [Water] [    ] [10]
3. [Juice]   [  1] [    ]

The GUI should display total of 990, and signal four errors: three 
missing values (ideally different color of the input fields), and the 
whole invoice incomplete. The Either [Error] Invoice type does not work, 
because can either display the errors or calculate total from a correct 
invoice, never both. And you can't even create LineItem for 2. and 3. 
Well, maybe you can with laziness, but how would total work then?

That's why I asked in my original post, whether I'd need two types, one 
for correct complete invoice, and another for the invoice "in statu 
nascendi". And how to obtain them, lazily, and I mean the person, not 
the language.

-- 
Wojtek