GÃnther Schmidt wrote:
> Hi guys,
> any suggestions on how to go about it then?
> I'm really still no step further on the DSL for Relational Algebra
> thingy, and I'd even settle for a "comprehension" DSL.
> I've spent months now, trying to figure it out by myself, studying
> HaskellDB, HList and many others. Yeah, I even had a look at LINQ.
> But there isn't really much around on this particular subject, so I
> figure that better minds than mine also haven't really solved this
> particular one yet, cause I'm sure it's been on the agenda.
In my opinion, Dan Leijen pretty much nailed it with HaskellDB. The idea
is that database queries aren't really different from working with plain
old lists, in particular with functions such as filter and concatMap
. See also chapter 5 in his PhD thesis:
Dan Leijen. The Î Abroad.
http://research.microsoft.decenturl.com/dan-leijen-phd-thesis :: pdf
Luke Palmer wrote:
> My way is to think hard about what the best way to think about things
> The best API design will come from inventing the perfect abstraction
I agree with Luke.
The downside of this approach is of course that it's quite difficult to
perform. After all, searching for a perfect abstraction means trying to
think in a way you never thought before. It involves a lot of time,
experience, simplicity and "taste", in particular for judging when an
abstraction doesn't cut it; and there's no guarantee that you'll
actually succeed in finding one.
That being said, I think that searching for abstractions is always worth
it; and there is much to gain by setting the bar a bit lower than the
"perfect" abstraction. Now, this doesn't mean to settle with a less
elegant abstraction - elegance should never be sacrificed - it means to
settle with a less comprehensive one.
In GÃnther's case, I would reduce the scope from finding an abstraction
that can solve every problem in relational algebra to one that can solve
most of problems that are relevant to GÃnther.
Judging from GÃnther's account of the problem domain, it even appears to
me that list comprehensions solve the problem just fine?
Haskell-Cafe mailing list