Simon, It would also work for my LDAP library where I had to invent new names for labels in records even though they were the same name in ASN.1. data LDAPResult = MkLDAPResult { resultCode_1 :: ResultCode, matchedDN_1 :: LDAPDN, errorMessage_1 :: LDAPString, referral_1 :: {- [3] -} Maybe Referral } deriving(Eq, Ord, Read) and data BindResponse = {- [APPLICATION 1] -} MkBindResponse { {- COMPONENTS OF LDAPResult -} resultCode_2 :: ResultCode, matchedDN_2 :: LDAPDN, errorMessage_2 :: LDAPString, referral_2 :: {- [3] -} Maybe Referral, serverSaslCreds :: {- [7] -} Maybe OctetString } deriving(Eq, Ord, Read) Daan, Would this be worth adding to the HToolkit repository? Dominic.
Dear Dominic, Simon,
Funnily enough, I'm currently ruminating on the possibility of adding extensible records to GHC. My current thought is: much like TRex, except with 'has' predicates instead of 'lacks' predicates.
I seem to remember that I have discussed "has" predicates once with Mark Shields and there seem to be some problems with it. Maybe it was just the polymorphic extensions but I am not entirely sure about that. Maybe you should contact Mark about this and ask his (expert) opinion.
Question: does anyone really care about polymorphic extension.
The extensibility of records is not a necessary feature for haskell/DB. The only reason haskellDB uses TREX is to share label names across different tables. However, during the implementation of haskellDB, I also used a technique where records are nested tuples. Labels can than be modelled as overloaded functions in multiple parameter type classes. Unfortunately, this lead to a lot of 'unresolved overloading' messages.
However, I believe that functional dependencies can be used nowadays to remedy this problem -- and thus use haskellDB on most Haskell systems. (I actually have a functional pearl in the works about modelling records with type classes and functional dependencies.)
Anyway: bottom line: your proposal is good enough for Haskell/DB and seems a *very* worthwile addition to Haskell.
Sorry that this message is a bit brief; I'm just back from a week away. I can elaborate if anyone would be interested.
Yes! I would love to hear more about it. :-)
All the best, Daan.
Simon
| -----Original Message----- | From: Dominic Steinitz [mailto:dominic.steinitz@blueyonder.co.uk] | Sent: 26 January 2003 10:19 | To: libraries@haskell.org | Cc: daan@cs.uu.nl | Subject: HaskellDB | | Having used HToolkit successfully to extract information from a MySQL | database, I am painfully aware of the limitations of sending embedded SQL | strings and finding out at runtime that something didn't quite work (in an | often subtle and difficult to track down way). | | I'd love to be able to put HaskellDB on top of HToolkit. There are two | approaches: i) add extensible records to ghc or ii) modify HaskellDB so it | uses Haskell records not extensible records (I'd have modify HaskellDB | anyway to use HToolkit rather than talk to ODBC directly). The latter sounds | as though it might be more feasible that the former. Having read the paper | and briefly looked at the code, I assume the extensibility is required if | you have two tables each with the same column name and therefore you want to | use the same label in two different records. Obviously you can't do this | with Haskell records as the labels become top level functions. However, if I | rename labels then I won't have this problem. For example, if I have two | tables, passwd and notify each containing a column called email then I could | have labels notifyEmail and passwdEmail and remember that they really | referred to email. | | Does anyone have any views on this? | | Dominic Steinitz | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries