New-ish to Haskell. Can’t figure out the best way to get Cassava (Data.Csv) to do what I want. Can’t tell if I’m missing some haskell type idioms or common knowledge or what.

Task: I need to read in a CSV, but I don’t know what the headers/columns are going to be ahead of time. The user will provide input to say which headers from the CSV they want processed, but I won’t know where (index-wise) those columns will be in the CSV, nor how many total columns there will be (either specified by the user or total). Say I have a [String] which lists the headers they want.

Cassava is able to read CSVs with and without headers.

Without headers Cassava can read in entire rows, even if it doesn’t know how many columns are in that row. But then I wouldn’t have the header data to filter for the values that I need.

With headers Cassava requires(?) you to define a record type instantiating its FromNamedRecord typeclass, which is how you access parts of the column by name (using the record fields). But in order for this to be well defined you need to know ahead of time everything about the headers: their names, their quantity, and their order. You then emulate that in your record type.

Hopefully I’m missing something obvious, but it feels a lot like I have my hands tied behind my back dealing with the types provided by Cassava.

Help greatly appreciated :)

  • mcmodknower
    2·
    1 year ago

    You could use the instances for parsing the data into a list of maps or hashmaps. At the bottom of the FromNamedRecord class, you can see that these instances are already specified in the library.

    If you need the data in a different format, converting them from a map might be easier than to write your own parser, depending on your abilities and requirements.

    • mrh
      1·
      1 year ago

      Ah yeah thanks that works! I didn’t think to look for already pre-defined instances of the typeclass. Though I still wonder how the Parser for Map/HashMap is defined, since Maps can hold an arbitrary number of values rather than a record’s fixed number of fields.

      I also wonder why (it seems) I need to put a type annotation that I want to decode the incoming data as a Map, since you don’t have to do that if you call e.g. a field accessor method on one of your custom record instances. That is, if you try to call Map.size on an incoming CSV record, you need to explicitly annotate with a type annotation that you want that record decoded as a Map. Whereas if you have a record data Foo = Foo {bar :: String} and define its parser in the standard way, you can just call bar on the incoming CSV record and it will work, no annotation required.

      • mcmodknowerEnglish
        2·
        1 year ago

        You can check the source code of nearly any class, instance, or function by clicking on the grey Source link on the right:

        You need to add type annotations for the map since with Map.size haskell can’t infer the types of the values inside the map. But for the deserialisation process, haskell needs to know the type inside the map. If you have a record, the types are already specified there.

        • mrh
          1·
          1 year ago

          Right Map is polymorphic while records are concrete, make sense.

          Those parser definitions in the source are enlightening, I see now I was thinking a bit narrowly about how e.g. parseNamedRecord could be instantiated for a type.