José Pedro Magalhães
writes:
Thanks Pedro,
On Fri, Dec 13, 2013 at 12:04 AM, Anthony Clayden wrote:
Questions: * These pile-ups of types (M1 D ... (M1 C ... (...))) seem hairy. Is that the best way to control the depth of recursion?
... The advantage of the "hairy types" you have right now is that these would be (obscure) compile-time errors.
OK. For this functionality, I prefer compile-time fail to run-time.
* The explicit data constructors in the pattern matching are a bit temperamental w.r.t. undefined values. ...
I don't see why you need |undefined| at all. Unless you are calling |tupToAttribs| with |undefined|; is that the case?
Yes: a relation (aka database table) could be empty, in which case I have only the type of its tuple, no value. (And actually, for a bit of background, this was the main point of the exercise: I am in debate on another forum about whether a relation needs a "heading" -- whose main purpose seems to be to deliver the attributes and their based-on types even when the relation (body) is empty. (The counter-argument is along the lines: how can a non-existent value have a type?) I'm claiming that you don't need a "heading", because you can reify the schema from the tuple type -- even if you don't have a tuple. And I now have a function to prove it, thank you Generics!) Cheers AntC