Re: [Haskell-cafe] Haskell Data Structure design

The implicit parameter approach is best if the environment never changes, or at least doesn't change during the computation You can rebind the variable in the middle of a computation, but it's not a good road to go down. The easiest way to simulate a changing environment is to use the State monad. There are other techniques: lenses, nested patterns, rebinding an implicit parameter, ST monad, generating a list of changes and applying the changes to the original state, etc. But - despite having to change your syntax somewhat - I think you'll find it easiest to use a state monad to manage this. Here's a somewhat verbose example of using State to track updates. You can make it less verbose, but I chose to keep it simple. In this example, it updates student_feesOwed as part of registering for a class. So we no longer need to calculate anything: It just grabs the value off of the Student. import Control.Applicative import Control.Monad.Trans.State.Strict import Data.Monoid import qualified Data.IntMap as M newtype RowId a = RowId Int deriving (Eq) data Classroom = Classroom { classroom_id :: RowId Classroom, classroom_extraFees :: Float, classroom_students :: [ RowId Student ] } data Student = Student { student_id :: RowId Student, student_name::String, student_feesOwed::Float} data Environment = Environment { environment_classroom :: Maybe Classroom, environment_students :: M.IntMap Student } student_totalFeesOwed :: RowId Student -> State Environment Float student_totalFeesOwed (RowId studentId) = do (Environment mClassroom students) <- get case mClassroom of Nothing -> return 0.0 Just classroom -> do let fees = student_feesOwed $ students M.! studentId return fees student_addFee :: RowId Student -> Float -> State Environment () student_addFee studentId fee = do modify $ \e -> e { environment_students = M.map (addFee studentId fee) $ environment_students e } where addFee studentId fee student = if studentId == student_id student then student { student_feesOwed = student_feesOwed student + fee } else student environment_addStudent :: Student -> State Environment () environment_addStudent student = do let (RowId key) = student_id student value = student modify $ \e -> e { environment_students = M.insert key value (environment_students e) } classroom_addStudent :: Classroom -> RowId Student -> State Environment () classroom_addStudent classroom studentId = do modify $ \e -> e { environment_classroom = addStudent studentId <$> environment_classroom e } where addStudent :: RowId Student -> Classroom -> Classroom addStudent studentId classroom = classroom { classroom_students = studentId : (classroom_students classroom) } student_registerClass :: RowId Student -> Classroom -> State Environment () student_registerClass studentId classroom = do student_addFee studentId (classroom_extraFees classroom) modify $ \e -> e { environment_classroom = Just classroom } classroom_addStudent classroom studentId main = do let studentId = RowId 1 student = Student studentId "Bob" 250.00 classroom = Classroom (RowId 1) 500.00 [] initialEnvironment = Environment Nothing mempty let totalFeesOwed = flip evalState initialEnvironment $ do environment_addStudent student student_registerClass studentId classroom totalFeesOwed <- student_totalFeesOwed studentId return totalFeesOwed putStrLn $ show totalFeesOwed On Tue, Jul 5, 2016 at 9:44 PM, Guru Devanla wrote:

Hi Michael,

That is excellent. I read about Implicit parameters after reading your post. I like this approach better than Reader monad for my current use case. I wanted to stay away from Reader Monad given that this is my first experimental project and dealing with Reader Monads into levels of nested function calls involved lot more head-ache for me.

That said, I plan to try this approach and also see how I can enable this set up in my HUnit tests as well.

One other question, I have regarding this design is as follows: Say, during the progress of the computation, the `student_feesOwed` changes, and therefore we have a new instance of classroom with new instance of student in it (with the updated feesOwed). I am guessing, this would mean, wrapping up this new instance into the environment from there on and calling the subsequent functions. Is that assumption, right. Nevertheless, I will play with approach tomorrow and report back!

Thanks Guru

On Tue, Jul 5, 2016 at 7:18 PM, Michael Burge wrote:

...

When I have functions that are pure but depend on some common state(say in a config file, or retrieved from a database at startup), I like to use implicit parameters to hide it. You can use a type alias to avoid it cluttering up most signatures. Below, a value of type 'Environmental Float' means 'A float value, dependent on some fixed environment containing all students and the single unique classroom'. If you have a deep chain of 'Environmental a' values, the implicit parameter will be automatically propagated to the deepest parts of the expression.

You could also use a Reader monad, but they seem to require more invasive syntactic changes: They are better if you later expect to need other monads like IO, but if you're just doing calculations they're overkill. You could also define a type alias 'Environmental a = Environment -> a', but then if you have multiple such states they don't compose well(they require you to apply the implicit state in the correct order, and it can be a little awkward to propagate the parameter).

Here's how I would start to structure your example in a larger project:

{-# LANGUAGE ImplicitParams,RankNTypes #-}

import qualified Data.IntMap as M

newtype RowId a = RowId Int

data Classroom = Classroom { classroom_id :: RowId Classroom, classroom_extraFees :: Float, classroom_students :: [ RowId Student ] } data Student = Student { student_id :: RowId Student, student_name::String, student_feesOwed::Float}

data Environment = Environment { environment_classroom :: Classroom, environment_students :: M.IntMap Student }

type Environmental a = (?e :: Environment) => a

classroom :: (?e :: Environment) => Classroom classroom = environment_classroom ?e

students :: (?e :: Environment) => M.IntMap Student students = environment_students ?e

student_totalFeesOwed :: RowId Student -> Environmental Float student_totalFeesOwed (RowId studentId) = classroom_extraFees classroom + (student_feesOwed $ students M.! studentId)

main = do let student = Student (RowId 1) "Bob" 250.00 let ?e = Environment { environment_classroom = Classroom (RowId 1) 500.00 [ RowId 1 ], environment_students = M.fromList [ (1, student) ] } putStrLn $ show $ student_totalFeesOwed $ RowId 1

On Tue, Jul 5, 2016 at 6:26 PM, Guru Devanla wrote:

...

Hello All,

I am just getting myself to code in Haskell and would like to design advice. Below, I have a made up example:

data ClassRoom = ClassRoom { classRoomNo:: Integer, extra_fees::Float, students: Map StudentId Student} data Student = Student {name::String, feesOwed::Float} data StudentId = Integer

get_fees_owed classroom student_id = extra_fees + feesOwed $ (students classroom) M.! studentid

Here the `get_fees_owed` needs information from the container 'classroom'.

Here is my question/problem:

I believe I should model most of my code as expressions, rather than storing pre-computed values such as `fees_owed`. But, defining expressions involve passing the container objects all over. For example, deep down in a function that deals with just one `student`, I might need the fees owed information. Without, having a reference to the container, I cannot call get_fees_owed.

Also, I think it hinders composing of functions that just deal with one student at a time, but end up with some dependency on the container.

I have several questions related to this design hurdle, but I will start with the one above.

Thanks! Guru

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.