Thor Michael Støre 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
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 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
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
