Would't this be a good solution to the partial null fields probleme?

--The field name and the value
type Field = (String,String)

--The form informations we get from the client
type FormResult = [Filed]

--An error message to send to teh client
type FormError = String

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

type PersonParseResult = Either FormError Person

--When receiving data froom the client you call this function and return the error to the client or continue normaly
getPersonneFromForm :: FormResult -> PersonParseResult

--You could go furter and do this:
class FromForm a where
    fromForm :: FormResult -> Either FormError a

instance FromForm Person where
    fromForm a = getPersonneFromForm a

--And then you could do this:
thisFunctionGetAForm :: FormResult -> HTTPResponse
thisFunctionGetAForm f =
    case (fromForm f) :: PersonParseResult of
        Left  a -> toHTTPResponse "The form is invalid"
        Right a -> toHTTPResponse "Ok, we got you"



2014-08-14 11:11 GMT-04:00 Wojtek Narczyński <wojtek@power.com.pl>:
On 14.08.2014 16:44, ok@cs.otago.ac.nz wrote:
It may be familiar, it may be popular, but the answer
is beyond any reasonable question simply WRONG.

The exactly advantage of a purpose built app over a spreadsheet is that it would not let you save the invoice in this state. Indeed, perhaps it is a good idea to tell the users that this sum is not their final value. For example display a marijuana leaf next to it. Although, I would rather use color for that.


(The emphasis on NEVER is mine.)  I guess now we know one
more reason why spreadsheet errors are ubiquitous: the
interface is broken by design.

I like spreadsheets, but they are not an answer to every need.



I have no idea what is customary, but I for d--n sure would not
use a spreadsheet to do it!  (This being a Haskell mailing list,
I would investigate the abilities of hLedger.)

Sorry, hledger is a double entry accounting system, it does not issue invoices.


So in the end you admit that my "design" (scratch, rather) might be what
young people might like?
On the contrary. You are specifying a design that lets invalid data
enter into computations. I'm saying they would like a design that
stops invalid data as early as possible.  This is close in spirit
to the Foo/FooBuilder distinction, where a Foo is never allowed to
be in an invalid state.


Pardon me, but are you "young people"?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Viva Cila