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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
