[Haskell-cafe] representing spreadsheets
Eric Rasmussen
ericrasmussen at gmail.com
Sat May 28 02:22:41 CEST 2011
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.solla at gmail.com>wrote:
> On Fri, May 27, 2011 at 3:11 PM, Eric Rasmussen <ericrasmussen at 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]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110527/b60b3dc0/attachment.htm>
More information about the Haskell-Cafe
mailing list