Thanks! I think GADTs may work nicely for this project, so I'm going to start building it out.
On Fri, May 27, 2011 at 4:16 PM, Alexander Solla <alex.so...@gmail.com>wrote: > On Fri, May 27, 2011 at 3:11 PM, Eric Rasmussen > <ericrasmus...@gmail.com>wrote: > >> Stephen, thanks for the link! The paper was an interesting read and >> definitely gave me some ideas. >> >> Tillmann -- you are correct in that it's very similar to a database. >> >> I frequently go through this process: >> >> 1) Receive a flat file (various formats) of tabular data >> 2) Create a model of the data and a parser for the file >> 3) Code utilities that allow business users to >> filter/query/accumulate/compare the files >> >> The models are always changing, so one option would be to inspect a >> user-supplied definition, build a SQLite database to match, and use Haskell >> to feed in the data and run queries. However, I'm usually dealing with files >> that can easily be loaded into memory, and generally they aren't accessed >> with enough frequency to justify persisting them in a separate format. >> > > "Worth it" in what terms? You're either going to have to encode the > relationships yourself, or else automate the process. > >> >> It's actually worked fine in the past to code a custom data type with >> record syntax (or sometimes just tuples) and simply build a list of them, >> but the challenge in taking this to a higher level is reading in a >> user-supplied definition, perhaps translated as 'the first column should be >> indexed by the string "Purchase amount" and contains a Double', and then >> performing calculations on those doubles based on further user input. I'm >> trying to get over bad object-oriented habits of assigning attributes at >> runtime and inspecting types to determine which functions can be applied to >> which data, and I'm not sure what concepts of functional programming better >> address these requirements. >> >> > My intuition is to use some kind of initial algebra to create a list-like > structure /for each record/ For example, with GADTs:. > > data Field a = Field { name :: String } > data Value a = Value { value :: a } > > > > Presumably, your data definition will parse > > into: > data RecordScheme where > NoFields :: RecordScheme > AddField :: Field a -> RecordScheme -> RecordScheme > > > And then, given a record scheme, you can > > construct a Table running the appropriate > > queries for the scheme and Populating its > > Records. > > data Record where > EndOfRecord :: Record > Populate :: Value a -> Record -> Record > > type Table = [Record] > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe