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. That would give polymorphic field selection and update but not polymorphic record extension So the main thing you *wouldn't* be able to do, that TRex can handle is: f :: (r\l) => {r} -> {r | l::Int} f x = {x | l = 3} Main reason: I'd like to translate records into tuples in the intermediate language, and polymorphic extension is problematic. On the other hand, you *could* do all the other things TRex supports, such as f :: (r has l::Int) => r -> Int f x = x.l f :: (r has l::Int) => r -> r f x = x { l <- 3 } (Syntax uncertain.) Question: does anyone really care about polymorphic extension. Sorry that this message is a bit brief; I'm just back from a week away. I can elaborate if anyone would be interested. 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
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
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
Simon Peyton-Jones writes: | 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. That would | give | polymorphic field selection and update | but not polymorphic record extension : | Question: does anyone really care about polymorphic extension. Yes! But my reasons are of dubious merit, so I'd better come clean and state them. - When handling records which have come out of a database (or EDI file or suchlike), with the results needing to go into a database too, I find I tend to copy some fields directly into the result record, from fields of the same name in other records. (COBOL, anyone? move by name rec1 to rec2.) - Some time in the future (Haskell 2?), I'd like to see convergence between Haskell's module system and records. Records with polymorphic extension would be a step in that direction: they'd support reexporting as in: module A(f, g, module B) where import B ... Have you considered asymmetric merge, as an alternative to Trex-style extension? For example, this function f x = x { l <- (3::Int) } would have this type f :: (r has l::Int) => r -> r
Sorry about sending the previous message unfinished, and with the final line downright wrong. (Unfamiliar new desktop, grumble, fulminate...) Continuing: With asymmetric merging, this function f x = x { l <- (3::Int) } would have type r -> (l::Int | r) regardless of whether r already had an l field. The one explicitly added by f would take precedence. Changing the tentative syntax a little, we could unify the record creation and record updating syntax. r1 = ( foo = (), bar = 'q' ) r2 = ( bar = "", baz = const ) g x = ( foo = id, qux = True | r1 | r2 | x ) -- g ( qux = LT, quux = EQ ) -- = ( foo = id, qux = True, bar = 'q', baz = const, quux = EQ ) As long as the higher-precedence side of the asymmetric merge (e.g. the part to the left of any '|' in the above example) has a fixed set of field labels, the types don't get too hairy. - Tom
participants (4)
-
Daan Leijen -
Dominic Steinitz -
Simon Peyton-Jones -
Tom Pledger