On Fri, May 27, 2011 at 3:11 PM, Eric Rasmussen 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]

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 wrote:

On Fri, May 27, 2011 at 3:11 PM, Eric Rasmussen 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]