<p>What about</p>
<p>data Foo = X { a :: Int }<br>
data FooLifted = XLifted { aLifted :: Maybe Int }</p>
<p>As I indicated earlier. Sorry for not being more eloquent on my phone.<br></p>
<p>Aristid </p>
<div class="gmail_quote">Am 06.05.2011 11:48 schrieb "Michael Snoyman" <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>>:<br type="attribution">> So a quick review: we have a few general approaches here:<br>
> <br>> 1) Create a few different datatypes, or a single datatype with<br>> multiple constructors.<br>> 2) Somehow annotate the fields to indicate that data may or may not be present.<br>> 3) Fill in some dummy values for fields not loaded.<br>
> <br>> I think option (1) is by far the most type safe. It's also the most<br>> involved and unintuitive. Greg's point about multiple constructors<br>> being ugly is very true. And two datatypes will be hard to manage.<br>
> <br>> Option (2) will work, but it's significantly less type safe. There's<br>> nothing at the type level distinguishing "get" and "getPartial". And<br>> it will have a strongly negative impact on all code branches using<br>
> "get".<br>> <br>> Option (3) is not as type-safe as option (1). In it's scariest form,<br>> it's going to allow undefined to float around programs wreaking havoc.<br>> In its more benign form, it will simply allow the user to provide<br>
> dummy values. The downside versus option (1) is that there's nothing<br>> at the type level distinguishing get from getPartial. The downside<br>> versus option (2) is that there is nothing at the value level<br>
> distinguishing get from getPartial.<br>> <br>> But the advantage of (3) is that it's much simpler to implement and<br>> will have no effect on regular code at all. I think it's also much<br>> easier to understand how to use it to someone.<br>
> <br>> Anyone see something I'm missing?<br>> <br>> Michael<br>> <br>> On Fri, May 6, 2011 at 7:49 AM, Aristid Breitkreuz<br>> <<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>> wrote:<br>
>> How about generating a version of the records lifted to Maybe?<br>>><br>>> Am 06.05.2011 04:03 schrieb "Max Cantor" <<a href="mailto:mxcantor@gmail.com">mxcantor@gmail.com</a>>:<br>>>> Personally, I vote against this. Putting in undefineds maintains<br>
>>> type-safety. However, in my mind the primary purpose of static type-safety<br>>>> is the avoidance of runtime errors. This only encourages that. Perhaps a<br>>>> better approach is to have some a TH function to generate "subselects" which<br>
>>> would be records that only contain the requested data. Its a bit more<br>>>> constraining, but I fear that the alternative is tantamount to curing the<br>>>> disease by killing the patient.<br>
>>><br>>>> furthermore, I worry that allowing undefined's here will start a slippery,<br>>>> runtime-error-laden slope which we're better off avoiding..<br>>>><br>>>> max<br>
>>><br>>>><br>>>><br>>>> On May 5, 2011, at 9:55 PM, Michael Snoyman wrote:<br>>>><br>>>>> That's interesting: I'd never considered the idea of inserting<br>
>>>> undefined into fields you want excluded... That could work. The reason<br>>>>> I've avoided putting in this (often requested) feature is that I could<br>>>>> think of no way to do so and keep type safety. That might be an<br>
>>>> approach.<br>>>>><br>>>>> We may consider requiring the user to supply the value instead,<br>>>>> thereby avoiding the library inserting undefined.<br>>>>><br>
>>>> Michael<br>>>>><br>>>>> On Thu, May 5, 2011 at 4:32 PM, Greg Weber <<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>> wrote:<br>>>>>> An alternative to laziness would be selecting a subset of fields. There<br>
>>>>> is<br>>>>>> no support for this directly in persistent, but it might be possible to<br>>>>>> add<br>>>>>> it and the future and have the value of an unselected field be something<br>
>>>>> like undefined.<br>>>>>> At the moment you can select sub fields by dropping down to lower-level<br>>>>>> sql<br>>>>>> methods (ask Michael about these methods if you are interested). I think<br>
>>>>> there is a technique for building your persistent data structure back up<br>>>>>> from the return of raw sql, which again you might be able to do by<br>>>>>> inserting<br>
>>>>> dummy error fields.<br>>>>>> Greg Weber<br>>>>>><br>>>>>> On Thu, May 5, 2011 at 4:18 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>>>>> wrote:<br>>>>>>><br>>>>>>> On Thu, May 5, 2011 at 1:28 PM, Felipe Almeida Lessa<br>>>>>>> <<a href="mailto:felipe.lessa@gmail.com">felipe.lessa@gmail.com</a>> wrote:<br>
>>>>>>> On Thu, May 5, 2011 at 2:20 AM, Jeremy Hughes <<a href="mailto:jedahu@gmail.com">jedahu@gmail.com</a>><br>>>>>>>> wrote:<br>>>>>>>>> Is Database.Persistent lazy wrt reading fields? I need to iterate<br>
>>>>>>>> over<br>>>>>>>>> entities containing both small and large fields. I do not need to use<br>>>>>>>>> the large fields in this instance, and so would rather they were not<br>
>>>>>>>> read from the database.<br>>>>>>>><br>>>>>>>> IIRC, they are read strictly. I guess you should put them on a<br>>>>>>>> different entity.<br>
>>>>>><br>>>>>>> That's correct. In fact, Persistent avoids any form of lazy I/O to<br>>>>>>> ensure that database connections are returned to the pool as soon as<br>
>>>>>> possible (amongst other reasons).<br>>>>>>><br>>>>>>> Michael<br>>>>>>><br>>>>>>> _______________________________________________<br>
>>>>>> web-devel mailing list<br>>>>>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>>>>>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
>>>>><br>>>>>><br>>>>><br>>>>> _______________________________________________<br>>>>> web-devel mailing list<br>>>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>
>>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>>>><br>>>><br>>>> _______________________________________________<br>
>>> web-devel mailing list<br>>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
>><br></div>