[Haskell-cafe] Finally tagless and abstract relational Algebra

[Günther Schmidt]

Dear Jacques,

I'll try to explain by a concrete example and what I'm hoping to achieve.

my app imports 4 CSV files, generated from a hospital's IT system and 
nationally standardized (Germany).

Theses 4 files contain records of how much money the hospital received 
for a patient, when he was initial admitted, what kind of procedures a 
patient had and when, his transfers and stays from departments within 
the hospital and his initial admission date. The common key in all these 
different kind of records is a patient's case-id.

 From all this information and more I calculate through a very 
complicated scheme a departments share of the revenue created for a 
individual patient. Well not even patients as such but rather 
hospital-case. The scheme is rather complicated and a bit of a moving 
target, because the auditors in a hospital do have the possibility to 
redistribute shares from one department to another. For instance revenue 
shares on surgical procedures may be redistributed from a non-surgical 
department to a surgical one and so on.

Initially I had simply imported the CSV files into empty tables in a 
database and done the calculations directly in SQL, never ever again!

The algorithms for looking up values in one table and matching them with 
the next, and sometimes creating new values, for instance figuring out 
in which department a patient had which procedures, those I'd like to 
express concisely and abstractly. Because I may or may not choose to 
evaluate the algorithm then to in-memory haskell code, using Maps or 
what-have-you or to compile to SQL, or whatever. But my 1st goal here is 
to express the algorithm.

I figure if I have to change the abstract algorithm due to new 
requirements (but not the syntax), the concrete and probably more 
elaborate implementation follows suit automatically.

Günther



Am 28.12.09 17:49, schrieb Jacques Carette:
> Günther Schmidt wrote:
>    
>> I do know that I could express my algorithms via list-comprehension or
>> in a List Monad, all using tuples. And that would be concrete and
>> grossly inefficient.
>>      
> You should probably tell us what these algorithms accomplish, rather
> than how one implementation goes.  From a higher-level view of what
> you're trying to do [but not as high as saying 'implement abstract
> relational algebra'], it will be easier to give concrete advice.
>
>    
>> So how would it be possible to express selecting /field/ b from
>> /record/ x and field c from record y, creating record z, while making
>> sure that record x does have field b and record y does have field c? I
>> mean design a syntax for it?
>>      
> Perhaps you should tell us why you think you need records at all, and
> record sub-typing to boot.  You might well be right, but the
> higher-level requirements will have a much bigger influence on the
> design than anything else.
>
> Jacques
>