I think you need an approach that: (a) simply doesn't let you construct data with conflicts -- such constraints would be enforced by the data type constructors and "update" functions, and (b) deal with "update" by creating a new structure that is a modified version of some existing structure. This may seem very expensive, but (due to lazy evaluation and value sharing) isn't necessarily so, and you have to start somewhere. Once you have the basic structures working, you can try various ways to optimize them. I can't see what you're trying to do in detail, but I'd imagine a function (or several) something like this: makeLesson :: Subject -> Teacher -> Maybe (Teacher,Lesson) where the return value would be Nothing if there's a schedule conflict, and otherwise would contain the revised teacher resource allocation. Passing around updated Teacher schedules like this might, after a while, get to be unwieldy and would be a candidate for using a state transformer monad to represent the overall resource schedule, but as one who has recently learned Haskell, I'd suggest getting the hang of using the simple functional style first. #g -- At 07:47 12/07/03 -0700, Ron de Bruijn wrote:
Hi there,
I was almost certain that Haskell was a great language until I wanted to make a real usefull program and got the following problem.
I have data Lesson = Lesson Teacher SomeOtherProperties deriving Show
data Subject = Subject Name [Teacher] SomeOtherProperties deriving Show
data Teacher = Teacher TimeTable SomeOtherProperties
What I want is that when I put some lesson in my timetable, the resources needed for that lesson are used up, so for example the timetable of a teacher will fill with each lesson that it gives.
The problem is that when I "model" it this way, the state of the teachers that can give a certain subject will not change (suppose I have some function that fills one timeslot of the timetable of a teacher).
It makes it even harder, because of the fact that one teacher can teach multiple subjects.
In an OO-language I would simply let each element of the list of TeacherObjects of Subjects point to some TeacherObject, so it remembers it state, but that's anti-Haskell.
It's ofcourse possible to put a list of Subjects that a Teacher teaches in the data declaration of the teacher. But then there is no way of saying efficiently (O(1) Just a pointer or index):"Give me a list of all teachers that give Physics", and that's just what I need.
I could use a hashtable which includes the teachersobjects as values and the subjects as keys, but that isn't a very beautiful solution. This would give me(building of Hashtable O(n) and getting all teachers of some subject O(1)), so it would do.
I am almost sure there exist some nice way of doing this, because otherwise Haskell would be completely useless IMHO, but I don't know it.
Do you have any idea?
Greets Ron
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------------
Graham Klyne