Re: Records in Haskell

I should be clear that in my counter point I am using Ruby, not Haskell on those projects. In Ruby one can use a string for the name of a class (which will be evaluated later) and other general dynamic typing tricks to avoid cyclical dependencies. I have worked on one large Yesod project. I felt they were creating artificially shortened field names in some cases (that I found difficult to understand/remember) to try and ease the pain of large prefixed record selectors. However, Yesod does create all the records with prefixes in one module/file- so all the types are in there. They create a new model file for each model (conceptually, but not for a model representing simple embedded data). The model file can import all the record types. Personally I would prefer to define my type in the model file so I can quickly see my type with the related code if it were possible, but it seems that it isn't. On Thu, Sep 15, 2011 at 8:15 AM, Christopher Done wrote:

2011/9/15 Greg Weber :

...

Chris, Thank you for the real word experience report. I had assumed (because everyone else told me) that importing qualified would be much, much better than prefixing. I had thought that in your case since you are big on model separation that you would have liked having a separate file for each model to separate out all your model related code with. As a counter point, in all of my (MVC) web application projects, we do have a separate file for each model, and we like this approach. Each file usually contains a lot of "business logic" related to the model- the only relatively empty model files are ones that really represent embedded data. When I use MongoDB (which actually supports embedded data instead of forcing you to create a separate table), I will actually place the embedded models in the same file as the model which includes them.

Ah, this is because my approach to types is to put them in a ProjectName.Types.X module. I /do/ have separate modules for all my models, e.g.

$ ls Confy/Model/*.hs Confy/Model/Actions.hs Confy/Model/Driver.hs Confy/Model/Manuscript.hs Confy/Model/Proceedings.hs Confy/Model/SubmissionAuthor.hs Confy/Model/Token.hs Confy/Model/Activity.hs Confy/Model/Fields.hs Confy/Model/Message.hs Confy/Model/ReviewComment.hs Confy/Model/Submission.hs Confy/Model/Track.hs Confy/Model/Author.hs Confy/Model/FormField.hs Confy/Model/Papertype.hs Confy/Model/ReviewerPreference.hs Confy/Model/Tables.hs Confy/Model/User.hs Confy/Model/Conference.hs Confy/Model/Form.hs Confy/Model/Participant.hs Confy/Model/Review.hs Confy/Model/Template.hs Confy/Model/UserMeta.hs Confy/Model/Deadline.hs Confy/Model/LogEntry.hs Confy/Model/Period.hs Confy/Model/Role.hs Confy/Model/TH.hs Confy/Model/Utils.hs

I have my HaskellDB types and then I have my normal Haskell types which contain different fields to the database model.

But to put the /type/ in the model file itself causes cyclic import problems when I have to start caring about what imports what and then having modules that just contain types, etc. I find this to be quite laborious, I did it at first but it became a hindrance to development practice for me. Have you not found that you have this problem if you put types in the same modules as code in a large project? Examples welcome, too.

...

After my blog post complaining about records, I had a few people telling me that I can just use existing polymorphism to avoid the name-spacing issue. I collected the approaches here: http://www.yesodweb.com/wiki/record-hacks I didn't think any of those telling me what i should do had actually tried to do this themselves, particularly at any kind of larger scale. I am interested to see if anyone has experience trying this approach, or if you have considered it.

I considered that approach but never tried it, one would probably enlist the help of TemplateHaskell to do that approach properly. Maybe it's not so bad? I suppose I could try making a few branches in my project and try out this approach.