Multiple "pointers" to "objects"

[Graham Klyne]

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
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E