I'm slightly confused by this. Is it not the case with rails that many of the .rb files are generated via rails?
I think you're over thinking / pessimizing what happens with haskell code.
1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the subdir #root/Foo/Bar.hs
2) Types. when you're writing use case specific code, you are going to define use case specific types, and they will be declared.
More over, it is good practice to give explicit type ascriptions to haskell code to make sure that it does in fact have the type you expect.
This means that you can jump into a module and by also recursively looking at its imports (and you know where those are in the fs), you can figure out exactly whats going on.
3) cabal-install (cabal), and your project specific project.cabal file make life great.
Why? the foo.cabal file will tell you which module has the Main function if you're making an executable, what other packages (and their versions) your code might be importing, which language extensions are enabled, etc.
Point being, there are no need for "framework specific conventions" of the sort you're concerned about because those problems are solved by Haskell specific conventions :)
I mean to specify higher level design conventions, as in the structuring decisions you'd have to make in a non-trivial app.
For instance, my experience with Express. The popular Peepcode screencast makes a Django'esque `apps` directory and modularizes the granular components of the entire app. Other people make an `app` directory and model the familiar Rails MVC. Some people contain controller logic in the router. Some people export routes from smaller files into app.js under a `//routes` comment. Sometimes the connection to the database is bootstrapped when the server starts in app.js. Sometimes the database is accessed from each model. Sometimes the database is accessed from each route. And you're guaranteed to have to dig into every required file to see how they exposed its API. Did they module.exports the entire object? Or did they individually export each public method?
See, I'm not criticizing unopinionated frameworks. They're for people that are opinionated and want to write the code that glues their opinionated structure together. Or for apps small enough to get by without deliberated structure.
But in a discussion about productivity, perhaps there's something to be said when people with experience making non-trivial apps have corroborated conventions and practices for a community to share.
Firstly: no, it should not be the case that many of the .rb files are generated via rails. Or at least, it shouldn't be. Generators are a crutch.
Secondly: the sort of conventions you're talking about in Haskell modules also exist in Ruby. They just aren't enforced by the compiler, and because Rails is an application framework rather than a library, it has its own set of completely different conventions which make sense for application code. This is a double-edged sword. On the one hand you get a convention which makes more sense for the specific type of application Rails assumes you're building; on the other you are encouraged to write code which may end up difficult to extract out of the application you're writing, and may be less well-designed because of it.
I think you're over thinking / pessimizing what happens with haskell code.
1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the subdir #root/Foo/Bar.hs
2) Types. when you're writing use case specific code, you are going to define use case specific types, and they will be declared. More over, it is good practice to give explicit type ascriptions to haskell code to make sure that it does in fact have the type you expect. This means that you can jump into a module and by also recursively looking at its imports (and you know where those are in the fs), you can figure out exactly whats going on.
3) cabal-install (cabal), and your project specific project.cabal file make life great. Why? the foo.cabal file will tell you which module has the Main function if you're making an executable, what other packages (and their versions) your code might be importing, which language extensions are enabled, etc.
Point being, there are no need for "framework specific conventions" of the sort you're concerned about because those problems are solved by Haskell specific conventions :)