SYB Documentation is inconclusive.
L.S., lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like:
totable :: [RecordType] -> [[String]] totable rs = fields (head rs) ++ map showrecord rs where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a showrecord = gmapQ (show . toConstr)
However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records. Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself. So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to? Doei, Arthur. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
Arthur, constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/DataCon.lhs; and that abstract syntax promises to be order-preserving. It says (not surprisingly): dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity. gmapQ maps the children to results. Since it is a map, it is order-preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr). So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order? Let me know if I don't get what you are after ... perhaps in the café. Ralf
-----Original Message----- From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Arthur van Leeuwen Sent: Thursday, November 23, 2006 12:09 AM To: haskell@haskell.org Subject: [Haskell] SYB Documentation is inconclusive.
L.S.,
lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like:
totable :: [RecordType] -> [[String]] totable rs = fields (head rs) ++ map showrecord rs where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a showrecord = gmapQ (show . toConstr)
However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records.
Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself.
So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to?
Doei, Arthur.
--
/\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 23-nov-2006, at 23:22, Ralf Lammel wrote:
Arthur,
constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/ DataCon.lhs; and that abstract syntax promises to be order-preserving.
It says (not surprisingly):
dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity.
gmapQ maps the children to results. Since it is a map, it is order- preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr).
So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order?
Such a promise would have been nice. I assumed that The Right Thing (as in no magic reorderings) would happen, but it was unclear from the papers and the haddock documentation. I should've looked into the source, of course, as that is the definitive documentation. :)
Let me know if I don't get what you are after ... perhaps in the café.
You have fully understood and explained. Glad to see that The Right Thing is done. Now I can safely go and let my code into the hands of unsuspecting non-Haskellers. :) With regards, Arthur van Leeuwen. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
participants (2)
-
Arthur van Leeuwen -
Ralf Lammel