Thor Michael Støre <thormichael <at> gmail.com> writes:
After much scratching of my head over intricate parts of this
"Haskell" thing
I'm happy to announce that I've finally released my first effort in it: HaskRel.
Thank you and congratulations on dipping your toe in the water. Was it very painful coming from Java ;-) ? [transferring to the cafe for discussion.] I see you're claiming to base HaskRel on ttm. I'm afraid the more I look, the less ttm-like it looks. Perhaps I should explain that looking like ttm doesn't just mean being different to SQL. HaskRel just seems to be a way of holding sets of records, supporting some relational-like operators over those sets. The records don't appear very like ttm tuples. Take an example relation value from that hackage page: let foo = relation' [( 10, "foo" ),( 20, "bar" ) ] :: Relation '[Attr "asdf" Int, Attr "qwer" String] The function /relation'/ presumably takes a list of Haskell tuples, and converts it to a HaskRel relation. The equivalent(-ish) Tutorial D would be: foo := REL{ TUP{ asdf 10, qwer "foo" }, TUP{ asdf 20, qwer "bar"} } (OK, compared to the HaskRel I've omitted the INT and CHAR signatures for attributes asdf and qwer respectively.) What is not apparent to me in the HaskRel syntax is whether we have each tuple being a set of <A, T, V> triples. I think it's okay to omit the T (type of the value) because in Haskell every value must be at a type. But in HaskRel the attribute is 'hidden' in the signature. (It's a "phantom type".) It seems you can't freely order tuples. This is exactly the same relation as the Tut D above: foo := REL{ TUP{ asdf 10, qwer "foo" }, TUP{ qwer "bar", asdf 20} } You can't reorder the attributes like that in HaskRel -- you'll get a type error. Having the Attribute names 'hidden' is going to be difficult for any operation needing to name attributes, such as: - projecting - renaming - extending - restricting (attrib names appearing in the WHERE expr) IOW Attribute names don't appear to be first-class values. (Did you consider making attributes data constructors -- newtypes, so getting <A, V> pairs explicit in the syntax. Perhaps that can be done with phantom types using proxy value constructors -- hmm seems messy.) I'm not sufficiently stimulated by what I've seen, to go hunting how HaskRel handles those operations. Given Haskell is a functional language, with first-class lambda expressions, this would have been a great testbed for the 'algorithmic relations' idea from HHT 1975. [see download on the ttm website, with comments by Hugh] On a Haskell state-of-the-art note: given all the heat around Haskell record system proposals, HaskRel doesn't seem to use any of them. (There's talk of Lenses for one flavour of HaskRel.) I'm not saying that's a wrong decision, but I'd like to understand the reasoning. Anthony