<div>I can think of 2 other approaches:</div><div>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.</div>
<div>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.</div><div>
<br></div><div>I didn't mention TH sub-selects idea because originally I didn't see how it was practical. Lets say that we force users to declare the possible sub-selects so that we avoid exponential TH. A first approach is for sub-selects be of the same data type as the full select.</div>
<div><br></div><div>data Person = PersonAll String String | PersonJustName String</div><div><br></div><div>For all your functions that operate on your data, you will now have to pattern match against all the declared permutations, and some of the pattern matches are going to result in runtime errors or dummy values. So it seems they should be different data types. But now we need to have the same functions operate over different types. So we need a bunch of typeclasses that define which fields are operated on.</div>
<div><br></div><div>data Person = Person String String</div><div>data PersonJustName = Person String</div><div><br></div><div>class PersonName p where</div><div> personName :: p -> String</div><div><br></div><div>instance PersonName Person</div>
<div> personName (Person name _) = name</div><div><br></div><div>instance PersonName PersonJustName</div><div> personName (Person name) = name</div><div><br></div><div>But I really don't know if the different data types means an entire re-working of Persistent, with even more obscure types. I will let Michael shoot this down :)</div>
<div><br></div><div>Greg Weber</div><br><div class="gmail_quote">On Thu, May 5, 2011 at 7:50 PM, Felipe Almeida Lessa <span dir="ltr"><<a href="mailto:felipe.lessa@gmail.com">felipe.lessa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, May 5, 2011 at 11:35 PM, Ian Duncan <<a href="mailto:iand675@gmail.com">iand675@gmail.com</a>> wrote:<br>
> Not sure that I feel *quite* so strongly about it as Max, but I agree with<br>
> his sentiments here. I'm not convinced that a proper implementation that<br>
> could deal with undefineds would be particularly error-prone, but I imagine<br>
> that performance would be better anyways with TH.<br>
<br>
</div>Although undefined isn't nice, it's kind of difficult to provide a TH<br>
solution. For example, if your entity has 20 fields, would you<br>
generate all 2^20 different combinations of this-field-is-not-needed<br>
datatypes? Would the data types be generated on the call site (this<br>
is impossible, however). So should the user specify on the persistent<br>
entity declaration that a field may not be needed? Even so, if you<br>
said that you may not need 6 fields, would you generate 2^6 different<br>
data types. Or should you tell not only which fields, but also which<br>
combination of fields? And what names would these data types get?<br>
<br>
IOW, this is complicated. =)<br>
<br>
The undefined route doesn't seem so bad. Actually, as Michael said,<br>
we could have the user pass a default value. Then you could use as<br>
default value 'error "fileX.hs, function foo, field zyw"' or something<br>
like that, giving you decisive information that you used an undefined<br>
field, and which field that was.<br>
<br>
Cheers,<br>
<br>
--<br>
<font color="#888888">Felipe.<br>
</font><div><div></div><div class="h5"><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" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</div></div></blockquote></div><br>