Records in Haskell

Greg Weber greg at
Thu Sep 15 17:45:15 CEST 2011

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
<chrisdone at>wrote:

> 2011/9/15 Greg Weber <greg at>:
> > 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:
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list