From: Brian B. <ph...@ho...> - 2009-05-16 22:08:11
|
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. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 |
From: Justin B. <jgb...@gm...> - 2009-05-18 15:39:37
|
I like the direction you are going. I looked into using HList a year or so ago and I wasn't quite up to it. The latest (unreleased) version of HaskellDB is on patch-tag at http://patch-tag.com/r/haskelldb/snapshot/current/content/pretty. Would you mind creating a patch file against that for easier review? I won't commit it until you say its ready but I'd like to see what changes you have made. No announcement has been made but I took over maintainership from Bjorn a few months ago. I hope to get a 1.0 release of HaskellDB out this summer, and having something new like this in it would be pretty sweet. On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> 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 > > |
From: Brian B. <ph...@ho...> - 2009-05-19 03:50:14
|
_________________________________________________________________ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 |
From: Brian B. <ph...@ho...> - 2009-05-19 14:23:35
|
Hi Justin, I updated my changes to apply against that repo, thanks for the pointer. Cool to see new changes to haskelldb, especially all the new unit tests! You can find my updated repo at: http://patch-tag.com/r/haskelldb-hlist Re-reading your email now, I see you asked for a patch, but seeing patch-tag for the first time I got excited and uploaded a whole new repo, whoops. Anyway, I had to do some minor surgery to update to the new version -- everything compiles, but I haven't tested much beyond that yet. Let me know if you have any questions. Thanks, -Brian > I like the direction you are going. I looked into using HList a year > or so ago and I wasn't quite up to it. The latest (unreleased) > version of HaskellDB is on patch-tag at > http://patch-tag.com/r/haskelldb/snapshot/current/content/pretty. > Would you mind creating a patch file against that for easier review? I > won't commit it until you say its ready but I'd like to see what > changes you have made. > > No announcement has been made but I took over maintainership from > Bjorn a few months ago. I hope to get a 1.0 release of HaskellDB out > this summer, and having something new like this in it would be pretty > sweet. > > On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> 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® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 |
From: Justin B. <jgb...@gm...> - 2009-05-27 19:12:30
|
Brian, Thanks for all your hard work here. I have a few comments: * 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, but the SQL operators are worrisome. How many conflicts are there? I'd rather see HList imported qualified rather than HaskellDB. * 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. * 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? * Finally, I am not sure I understand the implications of removing the Attr type. Can you elaborate? Justin On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> 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 > > |
From: Brian B. <ph...@ho...> - 2009-05-28 14:04:12
|
> * 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. http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009 |
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. |
From: Brian B. <ph...@ho...> - 2009-06-24 02:27:04
|
Hi Justin, > src\Database\HaskellDB\Query.hs:152:31: > Not in scope: type constructor or class `RecordValues' That's a part of some changes I made to hlist: http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz There were a few things which I thought would be generally useful for hlist, so I added them there. I mean to see if the HList devs were interested in merging the changes, but haven't gotten around to it yet. Thanks, -Brian _________________________________________________________________ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try_bing_1x1 |