Menu
▾
▴
Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList
|
From: Justin B. <jgb...@gm...> - 2009-06-22 22:22:37
|
Brian,
Sorry for the long delay in my reply. I am trying to build your
updated HaskellDB and am missing a "RecordValues" class:
src\Database\HaskellDB\Query.hs:152:31:
Not in scope: type constructor or class `RecordValues'
src\Database\HaskellDB\Query.hs:265:33:
Not in scope: type constructor or class `RecordValues'
src\Database\HaskellDB\Query.hs:551:10:
Not in scope: type constructor or class `RecordValues'
src\Database\HaskellDB\Query.hs:552:33:
Not in scope: `recordValues'
Is that in a file you forgot to add to the repo?
On Thu, May 28, 2009 at 6:59 AM, Brian Bloniarz<ph...@ho...> wrote:
>> * I am really uncomfortable with renaming the HaskellDB operators,
>> both SQL and record level "<<", "#" and "!". I can understand
>> replacing the record level stuff so HaskellDB code matches HList
>> documentation,
>
> While hacking, I was imagining a world where HList records were really well
> documented, and users might be familiar with the HList record syntax before
> they start using HaskellDB. This makes common syntax for records important.
> If you think of records as something universal that will eventually
> be provided by a good library, there's something to be said for HaskellDB
> not
> inventing it's own syntax.
>
> That well-documented world doesn't really exist yet -- the HList paper is
> really good but there's not much beyond that. I was hoping to improve
> HList's
> haddock when I get the chance, though.
>
> As an aside, my hope is that GHC eventually gets some support for extensible
> record syntax and/or first class labels, so there's no need for these
> band-aids.
>
>> but the SQL operators are worrisome. How many conflicts
>> are there? I'd rather see HList imported qualified rather than
>> HaskellDB.
>
> Yeah, having to qualify operators is nasty, I agree.
>
> The main problem is HList's (.*.) (a.k.a. record extension) -- it's a
> Record operation in HList and SQL multiplication in HaskellDB, and it's
> basically indispensible when working with records.
>
> There were other, probably less important conflicts: (.<.), (.+.) and (.-.).
>
>> * I notice "emptyRecord" had to be added to the queries in
>> TestCase.hs. Is it possible to define a new binary operator that does
>> not have to end with "emptyRecord", but has the Nil terminator
>> built-in? The (#) allowed that. Or is this a change introduced by not
>> having to have columns in the same order as the DB?
>
> I think the same "type Record r = RecNil -> r" trick would work.
> That's not how the HList people chose to implement it (there's
> even a short comment in the paper: "We could also consider implicitly
> terminated type sequences. Again, we require a terminating HNil
> to avoid a mess."), but I'm pretty sure it could be added in
> at the HaskellDB layer.
>
> This has a similar flavor to the operator issue -- do we want to think
> of HList as a library which we can encapsulate, and export their records
> under a custom guise? Or do we want to adopt HList Records as a common
> approach to records, and hope that syntax gets better eventually, through
> changes to HList or to the language?
>
> My original thinking was more the latter (partially because I'm interested
> in
> using Records for more than just databases). I think there are pluses and
> minuses on both sides, and I'm certainly happy to prepare patches which move
> in
> the first direction if you think that's the best way to go right now.
>
>> * Besides naming, do queries have to be rewritten? I am wondering if
>> it's possible to create a Compatability module for older code that can
>> export the new HList operators under the old HaskellDB names.
>
> Compatibility for queries is doable, I think. I don't think it's
> possible for table & label definitions.
>
> Just FYI, while I was hacking, I had in mind some further changes which
> would go father down the road of incompatibility -- that's for another email
> :)
>
>> * Finally, I am not sure I understand the implications of removing
>> the Attr type. Can you elaborate?
>
> Not sure if I understand _all_ the implications, but here's my version:
>
> I found it clunky in HaskellDB that there were two operators (.=.)
> and (<<) depending on whether you were working at the Record level or
> DB attr level. There's a comment in the "HaskellDB Improved" paper:
>
>> In order to make type inference of record selection easier and to get
>> a more TRex-like syntax, we wrap the actual field labels in a label
>> type which includes the type of the associated field value.
>
> I'm not sure about the "TRex-like syntax" part, because the syntax
> without Attr is only cosmetically different. When I got hacking, it
> seemed to me that inference was doable without Attr. As an example:
>
>> t1 <- table int_tbl
>> project $ f02 << (t1 ! f02) .+. constant 1
>
> The (t1 ! f02) .+. constant 1 gets inferred to be an Expr Int
> thanks to the type of t1. So why does (<<) need to fix the type of type
> of its second argument at all?
>
> In all the cases I looked at, inferring the types from the table definitions
> the expression operators was good enough. I looked closely at TestCases,
> I might have missed some other example.
>
> Thanks a lot for your feedback, I'm glad you're not disgusted yet :)
>
> -Brian
>
>> Justin
>>
>> On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz wrote:
>> > Hi,
>> >
>> > It's come time to share something that I've been playing around with
>> > recently:
>> > a branch of HaskellDB which replaces the home-grown Record code with
>> > HList
>> > records. It's definitely not ready for primetime, but I thought it'd be
>> > a
>> > good
>> > time to post the code and solicit some feedback from the community.
>> >
>> > HaskellDB the concept is very promising, but IMHO the code still falls
>> > short
>> > of that promise. Hopefully this is a small step in the right direction
>> > --
>> > the
>> > advantages of using HList:
>> > * Shared implementation of extensible records
>> > * Additional features from HList
>> > * Better error messages for record misuse
>> > * "Lacks" predicates
>> > * Simpler code
>> >
>> > As an example of how this can be better, a DB insert looks like so:
>> >> insert db table $ constantRecord $
>> >> film .=. "Munchie" .*.
>> >> director .=. Just "Jim Wynorski" .*.
>> >> emptyRecord
>> > The columns need not appear in the same order as in the database. If you
>> > forget
>> > a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
>> > Director)))"
>> > rather than an opaque error. Using the new "insertOpt" function, Maybe
>> > columns
>> > will default to Nothing rather than needing to be specified.
>> >
>> > The details:
>> >
>> > I haven't updated everything, but there's enough to run
>> > test/TestCases.hs
>> > under Postgresql. TestCases is probably the best place to look for
>> > examples
>> > of
>> > the new syntax for now.
>> >
>> > HList had name conflicts with HaskellDB's SQL expression language
>> > ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
>> > functions
>> > to Database.HaskellDB.SqlExpr, and require people to import qualified.
>> >
>> > The Attr type is gone, columns labels are untyped now. I also replaced a
>> > few instances of primitive type-level recursion with HMap/HMapOut. This
>> > makes
>> > the code simpler, and the type signatures more complex -- type families
>> > would
>> > help a lot here, I think.
>> >
>> > Feedback welcome! You can find my darcs tree at:
>> >
>> >
>> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
>> > It also requires minor changes to HList, available at:
>> >
>> >
>> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
>> > I'll talk to the HList people about getting those merged.
>> >
>> > Thanks!
>> >
>> > Brian Bloniarz
>> >
>> >
>> > ________________________________
>> > Hotmail® has a new way to see what's up with your friends. Check it out.
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Has...@ha...
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>
>
>
> ________________________________
> Hotmail® goes with you. Get it on your BlackBerry or iPhone.
|
