On Fri, May 6, 2011 at 12:31 AM, Greg Weber
1) lazy IO, but don't hold a connection open- accessing a lazy field creates an entirely new request. This means a change in the type signature of the field accessor to be in IO.
I think lazy IO is out of question. But I don't get this change in the type signature.
2) A to be excluded field must be nullable, and excluding it will return a Nothing. Instead of a runtime failure, you get a runtime wtf? moment if you don't realize why your data is not being displayed.
How would you find out if it is Nothing because you didn't ask for it, or if it's Nothing because it really is Nothing? There must be something to tell one situation from the other. So I guess this is not acceptable as well. But a similar approach may be acceptable: Person name String photo ByteString would become data Person = Person {name :: String, photo :: ByteString} But then you could say Person name String photo ByteString Large and then it would become data Person = Person {name :: String, photo :: Fetched ByteString} where data Fetched a = NotFetched | Fetched !a The good: - No combinatorial explosion. - No undefined values. The bad: - Can't statically check that everything was fetched, for example, when inserting. Some variants: a) Two data types data Person = Person {name :: String, photo :: ByteString} data PersonOpt = PersonOpt {nameOpt :: String, photoOpt :: Fetched ByteString} b) GADTs data Person t = Person {name :: String, photo :: Fetched t ByteString} data Fetched t a where NotFetched :: Fetched Incomplete a Fetched :: a -> Fetched Complete a data Incomplete data Complete Note that all names are terrible =(, but that's another bikeshed ;). Cheers, -- Felipe.