[web-devel] Database.Persistent

[Felipe Almeida Lessa]

On Thu, May 5, 2011 at 11:35 PM, Ian Duncan <iand675 at gmail.com> wrote:
> 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.