On Thu, May 5, 2011 at 11:35 PM, Ian Duncan
Not sure that I feel *quite* so strongly about it as Max, but I agree with his sentiments here. I'm not convinced that a proper implementation that could deal with undefineds would be particularly error-prone, but I imagine that performance would be better anyways with TH.
Although undefined isn't nice, it's kind of difficult to provide a TH solution. For example, if your entity has 20 fields, would you generate all 2^20 different combinations of this-field-is-not-needed datatypes? Would the data types be generated on the call site (this is impossible, however). So should the user specify on the persistent entity declaration that a field may not be needed? Even so, if you said that you may not need 6 fields, would you generate 2^6 different data types. Or should you tell not only which fields, but also which combination of fields? And what names would these data types get? IOW, this is complicated. =) The undefined route doesn't seem so bad. Actually, as Michael said, we could have the user pass a default value. Then you could use as default value 'error "fileX.hs, function foo, field zyw"' or something like that, giving you decisive information that you used an undefined field, and which field that was. Cheers, -- Felipe.