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@googlemail.com> wrote:
2011/9/15 Greg Weber <greg@gregweber.info>:
> 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.